snLibrary - Securing your Web-Application
While connection pooling is one aspect of a healthy application, as you would have already seen in my earlier blog, can we have a simple method for some sort of Application Authentication security? Certainly yes. If so, is it possible to achieve this with very little code?.
Can snLibrary help?
As we all know, application authenticity is established by way of challenging a user to authenticate himself/herself at the time of login. Once he/she logs in to the application, the web-container maintains a unique session for the link between the user and the application. As a keen observer, you would have often seen for yourself sometime during your childhood when you copied and pasted a URL (that was verily displayed on the address bar of your lovely browser) onto another browser or otherwise copied it and sent to your friend by email. And Lo!! have you not many times become very happy seeing that the page opened before you just as it would have, had you actually gone through the tiring process of Login to the application? If such an action did work perfectly well, then I would rather say that this certainly was (at least if it wasn't published intentionally), a poor programmer who did bad coding.
As an intelligent coder, you would certainly want to get out of such misadventure, if at all any time you experienced such a 'fault' in your own code (which are those rare events when you wanted to hide yourself from being laughed at!!). Some of you might have instructed your coders to put a line of code for verification in each of the web-page, wherein each JSP page would be verified for a session attribute, say user-id or so, before actually letting the code display the web-page. Yes indeed - let me also acknowledge that it is the right way!!. However, as it is often said, there is a lot between theory and practice. We have already seen that in theory we always would like our code to open and close all database connections in each page - but does that happen in practice? The answer is:- many times not. (Needless to say, many times while your coders would have done the verification in each web-page, they would have forgotten to put in the servlets or at least otherwise in those AJAX (Asynchronous Java And XML) called codes).
To overcome this, a small feature was provided in the snLibrary (since Ver-10.0 dtd. 20th Aug. 2010) which I named it the Indirect entry Redirection option. It means that if per chance, someone tries to access any page through 'indirect' means!!, then it would be redirected to the so called 'login' page. Such a feature can be implemented as follows.
Let us assume that there is one Login page and a Validation page/servlet. The Login page would be usually the welcome page of the Web-application (defined under the welcome tags of web.xml). Often, it is the page called 'index.jsp' or 'index.html' or any other that is defined in the web.xml under the 'welcome' tag. The Login page could be the one that would accept the user-id and password. Having accepted the credentials of the user, it would pass on to the Validation page. The validation page would validate and then if the credentials were acceptable, would proceed to other pages; otherwise take it back to the Login page (often with an error message).
User ------> Login.jsp ---> Validate.jsp -- if OK ----> ApplicationMainPage.jsp
User ------> Login.jsp ---> Validate.jsp -- if NOT OK ----> Login.jsp
However, there could be other pages which as a programmer you would wish to intentionally leave open without requiring to be authenticated as well. Such cases can be put in the 'exclusion' pattern list.
Thus we have three parameters namely:- the login page which I shall call the 'default_url', the validation page which I shall call the 'validator_url' and one or more pages that do not require any authentication (viz. the .bmp, .js, .css, .png, .gif, .jpg etc.) which I shall call the 'exclude_url-nnn'. These three patterns are defined as parameters in the web.xml under 'Indirect Entry Redirection Filter'. Include the following in the web.xml file.
File:- WEB-INF/web.xml
<filter><filter-name>Indirect Entry Redirection Filter</filter-name>
<filter-class>sessions.snIndirectEntryRedirectorFilter</filter-class>
<init-param>
<param-name>default_url</param-name>
<param-value>login.jsp</param-value>
</init-param>
<init-param>
<param-name>validator_url</param-name>
<param-value>login_validate.jsp</param-value>
</init-param>
<init-param>
<param-name>exclude_url-1</param-name>
<param-value>index_2.jsp</param-value>
</init-param>
<!-- Any webpage starting with /myfolder/index_, following with 3, 4 or 5 followed by a character and then jsp -->
<init-param>
<param-name>exclude_url-2</param-name>
<param-value>myfolder/index_[3-5].jsp</param-value>
</init-param>
<!-- Webpage starting with /myfolder/index_4.jsp, even though excluded by /myfolder/index_[3-5].jsp would get included -->
<init-param>
<param-name>include_url-2</param-name>
<param-value>myfolder/index_4.jsp</param-value>
</init-param>
<!-- Any word-character or dash (-) or slash (/) any number of times with extension gif,pdf,jpg etc. -->
<init-param>
<param-name>exclude_url-3</param-name>
<param-value>([\w||\-||/])+\.(gif|pdf|png|jpg|jpeg|bmp|js|css|swf|ico)</param-value>
</init-param>
<!-- Any word-character or dash (-) or slash (/) any number of times with extension GIF,PDF,PNG,JPG etc. -->
<init-param>
<param-name>exclude_url-4</param-name>
<param-value>([\w||\-||/])+\.([gG][iI][fF]|[pP][dD][fF]|[pP][nN][gG]|[jJ][pP][gG]|[jJ][pP][eE][gG]|[bB][mM][pP]|[jJ][sS]|[cC][sS][sS]|[sS][wW][fF]|[iI][cC][oO])</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>Indirect Entry Redirection Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
For this to work, there is just one more code to be put in the VALIDATED='TRUE' condition of the validator_url which is given below:-
File:-login_validate.jsp
import sessions.snAuthentications;
// ....
// ....
// ... Some part of the code goes here inside the Validate.jsp
// ...
if (valid_user_id) {
snAuthentications.properlyLoggedIn(request, response);
// ...
// ... Some other part of the code
// ....
}
// ....// ... Some other part of the code goes here
// ...
No comments:
Post a Comment