Server Security

• Firewall restrict IP access to FTP, SSH, database and control panel.
• Passwords are string, non-dictionary based.
• Version information hidden in request headers (PHP, Apache etc.)

Web Application Security

• SQL injection prevention.
• XSS filtering.
• Cookies sent via secure connection.
• Cookies encrypted.
• Session IP matching.
• Session user agent matching.
• SSL enabled on all areas handling user or login data.
• Code injection in input forms prevented (malicious strings removed).
• CSRF protection.
• User & admin passwords encrypted in database.
• Admin accounts in separate table from user accounts.
• No folder permissions set to 777.
• Folder browsing forbidden.

User Authentication

• Bespoke authentication and password hashing models, using crypt.
• Separate salts for user and admin logins.
• Session destroyed and recreated on permission level change.
• Session destroyed on browser close.
• DOS / Brute force attack prevention. Maximum 5 login attempts before ‘cool down period’.
• IP logging.

User File Uploading

• Allowed file types restricted.
• Stored outside of root directory, cannot be accessed directly.
• Virus scanned on upload.
• Accessible via authentication only, if user does not have permission to access that specific file, file not found is displayed.

RewriteRule ^(.+)\.aspx$ http://www.example.org/$1/ [QSA,NC,R=301,L]

This will redirect http://www.example.org/here.aspx to http://www.example.com/here/.

For a direct redirect from aspx to php, use the following:

RewriteRule ^(.+)\.aspx$ http://www.example.org/$1\.php [QSA,NC,R=301,L]

This will redirect http://www.example.org/here.aspx to http://www.example.com/here.php

Note that both of these rules also apply to longer urls:

http://www.example.org/home/something/this/here.aspx will become http://www.example.com/home/something/this/here.php

Don’t forget to enable redirects:
RewriteEngine On
RewriteBase /

#Force SSL for controllers admin, account & application
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} ^/(admin|account|application)
RewriteRule ^(.*)$ https://%{SERVER_NAME}/$1 [L]

# If not in list, run URL through Codeigniter
RewriteCond $1 !^(index\.php|assets|robots\.txt)
RewriteRule ^(.*)$ /index.php/$1 [L]

You will need to replace the REQUEST_URI controller names with your own, and also add any files or folders that need direct access to the last RewriteCond

Possible Error
[warn] _default_ VirtualHost overlap on port 443, the first has precedence.

Fix
Add NameVirtualHost *:443 to httpd.conf

The problem we developers face is that, although a client will have a general idea of what they would like the project to include, it will rarely be specific enough to write a brief at the beginning of the project.

This in itself would not be an issue except for the fact that we need to be able to assess the time required to complete any project and without a formal and structured list of features and functionality it is often difficult to estimate completion times. So what is the solution?

Get it in writing

One of the most effective methods of managing your client’s expectations is to spend a significant amount of time at the beginning of the project in discussions, this is necessary for the project but is also key to creating a comprehensive deliverables document. An agreement needs to be reached between the developer and client about what the project will deliver and in what format.

I often find that deliverables documents evolve through several versions before a final specification is agreed upon, and this is often once the compromise has been reached that although more features are required, the deadline the client has for the project will not allow for the addition of these. In cases such as this we would usually split the project into different phases, where the main launch would be considered ‘phase one’ and any additional features could be added into phase two, including revisions of functionality and design.

This approach keeps mid-development changes to a minimum as it allows the client to create a list of ‘phase two’ features, rather than them expecting every last-minute thought and addition to be incorporated into the original project specification.

Get it in detail

The problem that often occurs with this approach is that assumptions are made on both sides about features that are added to the deliverables document. This can often lead to complications as the client may expect that “Search Page for X” will include the ability to search for A, B and C, when being able to search for C alone will add several weeks worth of work to the project. This is a fault on both sides as clarifications were not made at the beginning about this.

Some obscurity is useful from the developer’s point of view as it can often afford them the freedom to change how a certain area is scripted in response to other factors, but as the project manager it is your role to ensure that all of the important details are included in the deliverables document to avoid any issues down the line.

This sounds simple but it will often involve planning the project to a very detailed degree before development even begins, although this in itself will usually be a benefit.

Communicate

Finally, the most important aspect of managing the client’s expectation is to communicate with them throughout the course of the project’s development. It may be easy to shy away from keeping the client involved to avoid them requesting additions that will not be possible, but managed correctly the client will be more comfortable with the progress of the project if they are kept involved as much as possible and are allowed to query if simple revisions can be made.
You will find that your relationship with the client will suffer more from lack of communication than from telling them ‘no’ but explaining why.

It turned out it  was an issue caused by one of the the plugins.  To disable the plugins in order to access WordPress’s back-end, follow these steps:

1. Log into your database.
2. “SELECT option_value FROM wp_options WHERE option_name = ’active_plugins’ LIMIT 1″
3. Remove all data from the field ‘option_value’. That will disable all plugins.
4. Log in to the wp-admin.
5. Update all plugins, and reactive.
6. Cross fingers

<meta http-equiv="content-type" content="text/html; charset=UTF-8" />

To fix this issues:

1. Close all instances of HeidiSQL
2. Open regedit.exe
3. Delete the entry \\HKEY_CURRENT_USER\Software\HeidiSQL\querymemoheight
4. Restart HeidiSQL

Luckily the solution is simple, all you need to do is add the following tag to yoursection and you should be good to go:

<meta http-equiv=”X-UA-Compatible” content=”IE=Edge” />

$ yum -y install subversion

CHECK INSTALLATION

$ svn –version

$ svnadmin –version

CHECKOUT REPOSITORY

$ svn checkout file:///tmp/repos/test folder

UPDATE FROM REPOSITORY (navigate to folder)

$ svn update

COMMIT TO REPOSITORY (navigate to folder)

$ svn commit -m “your commit message here”