I am working on a new shopping cart where all the action happens on one page in a simple non-distracted environment. PayJunction inc. will be the gateway I am using. I’ll keep you posted once I have made significant progress. If you have any specific question or issues you need addressed or even suggestions feel free to post your comments.
I have been working on a project on the Drupal 6 platform that requires the web application to recognize dynamically created sub-domains so the functionality of the database can be adjusted according to what sub-domain is in the current URL.
To get Drupal 6 to do this, I am creating a custom module. One of the things I have learned about creating a custom module in Drupal 6 is the implementation of the module’s “install” file.
If you create a module named say, my_module.module then the module’s install file name would be my_module.install and will reside in the directory named my_module located at….
my_site/sites/all/modules/my_module
Drupal 6 Module Install File Documentation
The .install file will be run by Drupal 6 the 1st time my_module has been enabled. The my_module.install file will then be used to run setup procedures as stipulated by your module. The most common task for the my_module.install file to perform is creating database tables and fields. There is no special syntax for the install file. It is simply a PHP file with a .install extension to properly identify it to the Drupal 6 platform.
There is special function used in the .install file called hook_schema(). Where hook would be replaced by the name of your module. For example, if the module you create is named my_module, then you would create a PHP file and name it my_module.install. Inside that file you will create a function named my_module_schema(). The my_module_schema() function is used to create arrays representingthe database tables you wish the module to create in the Drupal database. You can see how this works here.
Once you build the Drupal API Schema there is no more need for separate CREATE TABLE or ALTER TABLE statements on each database. As a module developer, you only need to create a schema structure and/or use the Drupal Schema API functions, and Drupal takes care of the rest. This greatly simplifies writing install and update functions.
This way of creating the module install files also allows for support in multiple database platforms.
According to Drupal’s Blog this also allows for “Several advanced capabilities, such as incremental database updates, a simple and consistent CRUD API, form scaffolding, simpler CCK and Views, schema and data validation, become much easier to implement in future enhancements.”
I am working on a web site that will be taking on many Individual Business Owners. The web site is designed to create sub domains created dynamically according to the input of users as they sign up for the service. Since the web site is expected to accommodate up to 30,000 users it would not be practical to edit the httpd.conf configuration file in Apache for each one. The file would simply grow to be enormous. The solution? Create wild-card sub domains.
Wild-card sub domains can be a great way to handle multiple sub domains that need to be created dynamically by making a simple edit to Apache via the terminal and some creative PHP programming.
The first step is alter Apache. There are a few ways to do this depending on how your server is set up.
Here are some links I have found on how to do this in various server environments;
NOTE: In the case of the project I am working on, we have a dedicated server by RackSpace. It was necessary to register the wild-card sub-domain ( *.you-domain.com ) with their name servers as well in order for this to work.
The first step is to create a wildcard DNS record. Your DNS server is already resolving visitors to domain.tld, but it doesn’t know where to resolve them to find subdomain1.domain.tld.
You’ll need to create what is called an “A record,” which is short for “address record.” As the name implies, “A records” tell what IP address a host is pointing to.
The way to do this will vary based on your DNS server and what control panel (or command line) you are using, most are somewhat similar. When you create a name record of type “A” pointing from *.domain.tld to your web server’s IP address.
If you are using a control panel, then likely you can set this using a web form. Sometimes have to get your web host to do this.
Your web server’s DNS service may need to be restarted. You can expext it to take a few hours or even up to a few days sometimes to propagate throughout the Internet.
Test and make sure it working by typing in a random sub-domain url to your site ( ie. Http://random-name.your-domain.com ). It should resolve to your site’s home.
Now that any sub-domain will point to your domain, you can use some PHP to determine what URL brought your user to your site. Once you have that knowledge you can manipulate the functionality of your site accordingly. Pretty cool!
One way to “recognize” the subdomain from the URL that brought you visitor is to use the a supper global ( which means they are available in all scopes throughout a script. There is no need to do global $variable; to access them within functions or methods) server variable called $_SERVER['HTTP_HOST'].
This super global variable will return the host name.
ie. sub-domain.your-domain.com
( if there is no sub- domain then it would just be the domain.com)
If you use PHP’s explode with “.” as the delimiter, you can isolate the sub-domain by separating out the first element of the resulting array of URL parts like this…
$url_sections = explode(”.”,$_SERVER['HTTP_HOST']);
$subdomain =$url_sections[0];
Knowing what sub-domain you’re dealing with gives you the PHP power to make you scripts act accordingly. In my case, I used the extracted information for the “virtual” sub-domain to query the MySQL database.
Wild card sub domains can useful for content management platforms like Drupal. With wild card sub domains and a little cleverness you can handle multiple sub domains within a single installation of Drupal.
It is very important that you do not have more than one URL (including the sub domain) point to identical content. Google penalizes for “duplicate content” so be sure not to carelessly point various unknown sub domains at your sites home page. With wild card sub domains, if a user makes a mistake and types in a misspelling then use PHP to redirect their page in some way that corrects them and then points them to the right page.
If you are dealing with this already and have any comments or suggestions or corrections feel free to post a comment.
Recently I was working on scripting the back end of a commercial site in PHP5. In this case the back end user interface permits users to upload rather large image files so that the files can be processed for ‘Zoomify’( a fast way of showing a highly detailed “zoomable” image). After making sure the process was secure, I also needed to change a few settings in the php.ini file in order for the system to allow files sizes of over 2 megs (the standard PHP5 default).
It is generally not wise to make these changes in the php.ini file itself unless you have a very good reason. The preferred way would be to make the required change at execution time for the particular script you happen to be running only. This gives you better control over site operations and security. To do this you use the “ini_set()” function.
To demonstrate how to do this, I will show you the code for the four changes I needed to make to my script to accommodate the large image uploads. First, I defined global variables that determine what the setting should be.
Defineing Globals in PHP
I do this so that later if I chose to edit the settings I can do so from my configuration file and not have to hunt through the script to make the changes. Also this allows me to duplicate the setting elsewhere if needed. The setting are as follows:
Also, If you are using a form to upload the file, do not forget to make the MAX_FILE_SIZE directive large enough to accommodate your file size. By the way, do not rely on MAX_FILE_SIZE as any sort of security measure.
Once I made these settings on my local testing server, all worked well. However, after the site was in the “live” pre production mode, the large file sizes would return an error. I knew it was not the file size issue because I had already compensated for that. What tipped me off to the problem was the fact that, every once in a while the file would upload with no error. That is when I realized it was not only a “memory limit” issue but also a timing issue. This did not show up at first because it takes much longer for a file to upload to a remote server than to the local server.
Settings we do not often deal with are easy to forget about and that was the case this time. Once I remembered to reset the “max_execution_time” to the appropriate amount of seconds, the files uploaded just fine.
As mentioned above, the maximum execution time limit is set in the php.ini file. The line of code in the php.ini file is:
Set the max_execution time in the php.ini file.
With this little line of code in your PHP script, you are now afforded 180 seconds of time to run your program. You can adjust the seconds as you wish by simply changing the number.
I hope this helps!
A really great feature of PHP it the ability to modify its behavior by altering its configuration file (php.ini).
By having the php.ini file, PHP has made it easier to change how it responds and beh
aves even after it has already been installed. What a pain it would be to have to re-compile every time you realize the need for a configuration change.
The php.ini file really helps make PHP more powerful and more secure as well. This is because you can configure PHP with secure settings until the setting need to change for some reason. Then you can also programmatically alter its behavior to accommodate a particular script file’s needs, on the fly, and returning the settings to normal when you’re done.
When PHP is booting, one of the first things it does is look at the php.ini file. It reads into memory the directives defined with in it. In most cases, when you compile PHP, it puts a copy of the php.ini file in /usr/local/lib/php. This may different depending upon your server.
If you are on a Unix machine, you may be able to type locate php.ini or find / -name php.ini -print and have it tell you the location of the php.ini file. If you have installed it on a Windows machine, use the “Find -> Files or Folders” option from the Start Menu.
One of the most common web security problems is SQL Injection. As the name implies, SQL injections works by introducing malicious SQL code where it doesn’t belong. Since it is SQL code you could probably guess that the attacker “injects” his poison via database queries. Web developers often pass some sort of variable to their database queries. Very common are variables that are influenced by user input. User input, to variable, then to query,- get it? So, there is a need for a way of eliminating the user’s ability to manipulate the variable in any way that could effect the query.
What Happens With SQL Injection
By passing an unexpected string of code into a user input, such a form, an attacker send damaging code that causes an otherwise good query to go haywire. For example: [Read more →]
Error reporting in PHP gives valuable insight during the development stages. This Insight can be a great aid to problem solving. There are others, however who are interested in why your web site has failed on occasion. The information thrown out by many PHP errors gives the kind of information about your web application that can make you vulnerable to crackers (malicious web site breakers). In fact apart from reading the code itself, error reporting is some of the most valuable intelligence an attacker can gather when looking for vulnerabilities in your web application.
So, what should be done once you launch your new web site? Well, as proud as you may be of your new creative geniuses, a wise web developer has the humility to recognize that bugs are still likely to surface from time to time. While you do not want any attackers to see error [Read more →]
Recently I had a little problem stump me while designing the back end of a commercial site. The back end user interface uploads rather large image files so that the files can be processed for ‘Zoomify’( a fast way of showing a highly detailed zoomable image). After making sure the process was secure, I also needed to change a few settings in the PHP ini file in order for the system to allow files sizes of over 2 megs. All was working great on the local testing server. [Read more →]
