Single entry point to the web application
In modern web applications, it is common 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 tremendous advantages, both at the creation stage and at the project support stage, since the redundancy of the code is drastically reduced, and for applications that manipulate dynamic content, a single entry point is the only correct solution.
These examples are relevant to the configuration of the apache web server.
The concept of a single entry point in the implementation is reduced to the fact that it is necessary to tell the web server to redirect all requests to the file to it, which will be our only entry point, even if 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 directive syntax is as follows:
')
A pattern is a perl-compatible regular expression that applies to the current URL, with the current meaning of the URL 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.
The substitution is a string that will replace the original URL for which there is a pattern match. In addition to the text in the substitution, you can use a lot of things, but so far we are only interested in the server variable REQUEST_URI.
Of the flags, we use only two - QSA and L. The first tells the transformation engine what to add, rather than replace, the query string from the URL to the existing one in the substitution string. The L flag tells the server to stop the conversion process at this location and not to apply any other translation rules.
Considering all the above, we add the following line to the .htaccess file in the application root directory:
But we should not forget that in addition to directly accessing the script, the browser will request the server for various resource files, such as cascading style sheets, images, files with scripts, etc. In order for the server to give the browser access to the desired, you need to set additional conditions for the RewriteRule directive. These conditions are described by the RewriteCond directive, which will determine when the conversion should be done in the URL or when it should be left unchanged.
Without going deep into details, I will give a few examples, and in more detail about the mentioned directives you can read the links given at the end of the article.
Looking at the above lines, you can immediately notice that they are comparing REQUEST_URI with the line described by a perl-compatible regular expression, and in case of a match, the URL is not substituted.
Note: One should not forget that all RewriteCond directives must be described before using the RewriteRule.
The above method is just one of the possible ways to consider how the concept is implemented in the Zend Framework. In the previous example, the entry point was assumed to be in the root directory of the web application, the default project structure based on the Zend Framework is different because the directory is shared moved to the lower 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. To gain access to resources outside the public directory, you must use conditional addressing in the script to return to a higher level or absolute addressing, which is not convenient at all, for example, you can do the following:
It remains to write the contents of the file public / .htaccess:
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 to them will be granted automatically, and access to application script files outside the public will be denied.
Mod_rewrite module documentation
These examples are relevant to the configuration of the apache web server.
The concept of a single entry point in the implementation is reduced to the fact that it is necessary to tell the web server to redirect all requests to the file to it, which will be our only entry point, even if 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 directive syntax is as follows:
')
RewriteRuleA pattern is a perl-compatible regular expression that applies to the current URL, with the current meaning of the URL 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.
The substitution is a string that will replace the original URL for which there is a pattern match. In addition to the text in the substitution, you can use a lot of things, but so far we are only interested in the server variable REQUEST_URI.
Of the flags, we use only two - QSA and L. The first tells the transformation engine what to add, rather than replace, the query string from the URL to the existing one in the substitution string. The L flag tells the server to stop the conversion process at this location and not to apply any other translation rules.
Considering all the above, we add the following line to the .htaccess file in the application root directory:
RewriteRule ^(.*)$ index.php?%{REQUEST_URI} [QSA,L]But we should not forget that in addition to directly accessing the script, the browser will request the server for various resource files, such as cascading style sheets, images, files with scripts, etc. In order for the server to give the browser access to the desired, you need to set additional conditions for the RewriteRule directive. These conditions are described by the RewriteCond directive, which will determine when the conversion should be done in the URL or when it should be left unchanged.
Without going deep into details, I will give a few examples, and in more detail about the mentioned directives you can read the links given at the end of the article.
RewriteCond %{REQUEST_URI} !^\/resources/styles/(.*).cssRewriteCond %{REQUEST_URI} !^\/resources/images/(.*).pngRewriteCond %{REQUEST_URI} !^\/resources/images/(.*).jpgRewriteCond %{REQUEST_URI} !^\/resources/lib/jquery/(.*).jsLooking at the above lines, you can immediately notice that they are comparing REQUEST_URI with the line described by a perl-compatible regular expression, and in case of a match, the URL is not substituted.
Note: One should not forget that all RewriteCond directives must be described before using the RewriteRule.
The above method is just one of the possible ways to consider how the concept is implemented in the Zend Framework. In the previous example, the entry point was assumed to be in the root directory of the web application, the default project structure based on the Zend Framework is different because the directory is shared moved to the lower 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. To gain access to resources outside the public directory, you must use conditional addressing in the script to return to a higher level or absolute addressing, which is not convenient at all, for example, you can do the following:
define( 'DIR_SEPARATOR ', '/' ); define( 'ROOT', '..' . DIR_SEPARATOR ); It remains to write the contents of the file public / .htaccess:
RewriteCond %{REQUEST_FILENAME} -s [OR]RewriteCond %{REQUEST_FILENAME} -l [OR]RewriteCond %{REQUEST_FILENAME} -dRewriteRule ^.*$ - [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 to them will be granted automatically, and access to application script files outside the public will be denied.
Mod_rewrite module documentation
Source: https://habr.com/ru/post/115389/
All Articles