I'm trying to use this with JSF instead of JSP, which I wouldn't expect would be a problem, however I ran into some interesting problems...
1.) h:commandLink tags aren't processed through the filter like I'd like them to be. Here's a code example:
<h:commandLink action="createIssue">Create New Issue</h:commandLink>
<a href="developer/issue.jsf">Create new issue HTML link</a>
The first one resolves to /developer/issue.jsf in accordance with my navigation rule (rule listed below for completeness). When I use the second link, it asks me to log in (as it should). When I use the first link, it just takes me directly to the page, effectively bypassing the SecurityFilter. I'm not familiar enough with the details of how a request is processed by a filter, and what's available at that time, so maybe this is a very difficult problem... or maybe I just need to flip a flag in the configuration... I'm not sure.
<security-constraint>
<web-resource-collection>
<web-resource-name>Secure page that the example user is not authorized to view</web-resource-name>
<url-pattern>/developer/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>developer</role-name>
</auth-constraint>
</security-constraint>
2.) The next problem also seems to be related to me using JSF tags instead of HTML tags. The h:form tag doesn't take an action attribute like the HTML counterpart does. Also, buttons work a little differently. Here's what I have for my login page:
<h:form id="login">
<h1><h:outputText value="Login" /></h1>
<p>Username: <h:inputText id="j_username" /></p>
<p>Password: <h:inputSecret id="j_password" /></p>
<p><h:commandButton value="Login" action="logMeIn" /></p>
</h:form>
My questions are: Can I use JSF tags? If so, how and if not, where would I start in the library to make this possible? (The above snippit doesn't work).
And in my attempt to not leave anything out:
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsf</form-login-page>
<form-error-page>/loginError.jsf</form-error-page>
<form-default-page>/index.jsp</form-default-page>
</form-login-config>
</login-config>
For those who were asking about JSF compatibility, and anyone else who finds this thread:
This can't be accomplished by a filter. When clicking on a commandLink, control is sent back to the server and a request is made from the requesting page. The filter happens entirely outside of the JSF life cycle, so getting it to work with things like commandLinks and other JSF tags just isn't going to happen.
It seems like the way to go is to either use a phaseListener (which I know very little about), or to just put a check on every page which will pull a session bean to check the login information. The drawback the the latter of the two is that you have to put code at the top of every protected page. Filters seem like the perfect option as long as you don't plan on using any <h:commandLink> tags or <h:form> tags, etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The filter, like classical container based authentification, work based on the url of the request and the servlet involved. The problem you mention is not related to filter, it's related to the way you have configured your navigation rule. If you want container managed security to be taken into account during your navigation, you must force this navigation to occur from outside of jsf, simply by adding <redirect/> to your navigation rule. That way JSF will send a response to client in which it asks borwser to change page. Avantage of this is also that the url shown in borwser is correct. Disadvantage is that request scoped bean are reinitialised during redirect. (Can be worked around using tomahawk redirect manager)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying to use this with JSF instead of JSP, which I wouldn't expect would be a problem, however I ran into some interesting problems...
1.) h:commandLink tags aren't processed through the filter like I'd like them to be. Here's a code example:
<h:commandLink action="createIssue">Create New Issue</h:commandLink>
<a href="developer/issue.jsf">Create new issue HTML link</a>
The first one resolves to /developer/issue.jsf in accordance with my navigation rule (rule listed below for completeness). When I use the second link, it asks me to log in (as it should). When I use the first link, it just takes me directly to the page, effectively bypassing the SecurityFilter. I'm not familiar enough with the details of how a request is processed by a filter, and what's available at that time, so maybe this is a very difficult problem... or maybe I just need to flip a flag in the configuration... I'm not sure.
<navigation-rule>
<description>Go to create issue page</description>
<navigation-case>
<from-outcome>createIssue</from-outcome>
<to-view-id>/developer/issue.jsf</to-view-id>
</navigation-case>
</navigation-rule>
<security-constraint>
<web-resource-collection>
<web-resource-name>Secure page that the example user is not authorized to view</web-resource-name>
<url-pattern>/developer/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>developer</role-name>
</auth-constraint>
</security-constraint>
2.) The next problem also seems to be related to me using JSF tags instead of HTML tags. The h:form tag doesn't take an action attribute like the HTML counterpart does. Also, buttons work a little differently. Here's what I have for my login page:
<h:form id="login">
<h1><h:outputText value="Login" /></h1>
<p>Username: <h:inputText id="j_username" /></p>
<p>Password: <h:inputSecret id="j_password" /></p>
<p><h:commandButton value="Login" action="logMeIn" /></p>
</h:form>
My questions are: Can I use JSF tags? If so, how and if not, where would I start in the library to make this possible? (The above snippit doesn't work).
And in my attempt to not leave anything out:
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/login.jsf</form-login-page>
<form-error-page>/loginError.jsf</form-error-page>
<form-default-page>/index.jsp</form-default-page>
</form-login-config>
</login-config>
<realm className="org.dc949.bugTrack.SecurityRealm">
<realm-param name="exampleProperty" value="it works!" />
</realm>
Forgot the web.xml configuration entry (which should enable me to post to "logMeIn")
<filter>
<filter-name>securityFilter</filter-name>
<filter-class>org.securityfilter.filter.SecurityFilter</filter-class>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/securityfilter-config.xml</param-value>
</init-param>
<init-param>
<param-name>validate</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>formPattern</param-name>
<param-value>/logMeIn</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>securityFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
For those who were asking about JSF compatibility, and anyone else who finds this thread:
This can't be accomplished by a filter. When clicking on a commandLink, control is sent back to the server and a request is made from the requesting page. The filter happens entirely outside of the JSF life cycle, so getting it to work with things like commandLinks and other JSF tags just isn't going to happen.
Here's some words on the subject from someone much more knowledgeable than myself:
http://www.thoughtsabout.net/blog/archives/000035.html
It seems like the way to go is to either use a phaseListener (which I know very little about), or to just put a check on every page which will pull a session bean to check the login information. The drawback the the latter of the two is that you have to put code at the top of every protected page. Filters seem like the perfect option as long as you don't plan on using any <h:commandLink> tags or <h:form> tags, etc.
The filter, like classical container based authentification, work based on the url of the request and the servlet involved. The problem you mention is not related to filter, it's related to the way you have configured your navigation rule. If you want container managed security to be taken into account during your navigation, you must force this navigation to occur from outside of jsf, simply by adding <redirect/> to your navigation rule. That way JSF will send a response to client in which it asks borwser to change page. Avantage of this is also that the url shown in borwser is correct. Disadvantage is that request scoped bean are reinitialised during redirect. (Can be worked around using tomahawk redirect manager)