Single entry point to web application

In modern web applications, it is customary to use the concept of a single entry point. This concept boils down to the fact that all requests to the application server are redirected to one file, which, based on the request parameters, coordinates the further behavior of the script. Such an approach offers enormous advantages both at the creation stage and at the project support stage, since code redundancy drastically decreases, and for applications that manipulate dynamic content, a single entry point is the only right decision.

The above examples are relevant for configuring the apache web server.

The concept of a single entry point in the implementation comes down to telling the web server to redirect all requests to it to the file, which will be our only entry point, for example, it will be the index.php file in the application root directory. For these purposes, the Apache web server has a RewriteRule directive located in the mod_rewrite module. The syntax of the directive is as follows:

RewriteRule Шаблон Подстановка Флаги

A pattern is a perl-compatible regular expression that applies to the current URL, and the current is the URL value at the time this rule is applied. This URL does not necessarily match the originally requested URL, because up to this point, other rules may have already been applied to this URL and converted it accordingly.
Substitution is a string that will replace the original URL for which there is a match for the Pattern. In addition to text, you can use a lot of things in the substitution, but so far we are only interested in the REQUEST_URI server variable.
Of the flags, we will use only two - QSA and L. The first indicates to the transformation mechanism what you need to add, not replace, the query string from the URL to the existing one, in the wildcard string. The L flag tells the server to stop the conversion process at this point and no longer apply any conversion rules.
Considering all the above, let's add the following line to the .htaccess file in the root directory of the application:

RewriteRule ^(.*)$ index.php?%{REQUEST_URI} [QSA,L]

But we should not forget that in addition to accessing the script directly, the browser will request various resource files from the server, such as cascading style sheets, images, script files, etc. In order for the server to give the browser access to the desired, additional conditions must be set for the RewriteRule directive. These conditions are described by the RewriteCond directive, which will determine when to convert to URL or when to leave it unchanged.
Without going deep into the details, I will give a few examples, and in more detail about the mentioned directives you can read the links at the end of the article.

RewriteCond %{REQUEST_URI} !^\/resources/styles/(.*).css
RewriteCond %{REQUEST_URI} !^\/resources/images/(.*).png
RewriteCond %{REQUEST_URI} !^\/resources/images/(.*).jpg
RewriteCond %{REQUEST_URI} !^\/resources/lib/jquery/(.*).js

Looking at the lines above, you can immediately notice that they compare REQUEST_URI with the line described by the perl-compatible regular expression, and in case of coincidence, URL spoofing does not occur.
Note: Remember that all RewriteCond directives must be described before using RewriteRule.

The method described above is just one of the possible, let's consider how the concept is implemented in the Zend Framework. In the previous example, it was assumed that the entry point is in the root directory of the web application, the default project structure based on the Zend Framework differs in that the shared directory taken down one level, by default its name is public and access to the web application is configured so that the public directory is the root of the application, i.e. in order to gain access to resources located outside the public directory, the script must use conditional addressing to return to a higher level or absolute addressing, which is not convenient at all, you can do something like this:
    define( 'DIR_SEPARATOR ', '/' );
    define( 'ROOT', '..' . DIR_SEPARATOR );
  
Thus, we got a constant containing the relative path to the logical root of our application.
It remains to write the contents of the file public / .htaccess:

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

Using the described approach, there is no need to set certain access rights to the public resources of the application, now we just need to put them in the public directory and access will be granted automatically, and access to the application script files located outside public will be closed.

Mod_rewrite module documentation

Also popular now: