Win a copy of Bad Programming Practices 101 (e-book) this week in the Beginning Java forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

How to Handle form Based Authorization in Struts2.5  RSS feed

 
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,

   I was working on Migration of Struts 1 to Struts 2.5. I have done the migration of other pages to Struts 2.5 but now i have difficulty in migrating my Login page to Struts 2.5. 
  
    Login page was a form based Authorization and now i need to migrate the same jsp file to Struts 2.5 with Form Based Authorization.

     Can anyone suggest have you ever implemented any such functionality if so how it can be done.

     I have Struts dispatched in my web.xml file but when i was trying load my login page i was getting Struts Dispatcher cannot be found.

     Thanks in advance for all your support.

Thanks and Regards,
Janakiram.
 
janakiram kota
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

janakiram kota wrote:Hello All,

   I was working on Migration of Struts 1 to Struts 2.5. I have done the migration of other pages to Struts 2.5 but now i have difficulty in migrating my Login page to Struts 2.5. 
  
    Login page was a form based Authorization and now i need to migrate the same jsp file to Struts 2.5 with Form Based Authorization.

     Can anyone suggest have you ever implemented any such functionality if so how it can be done.

     I have Struts dispatched in my web.xml file but when i was trying load my login page i was getting Struts Dispatcher cannot be found.

     Thanks in advance for all your support.

Thanks and Regards,
Janakiram.


Here is the complete Stack in server

ServletWrappe E com.ibm.ws.webcontainer.servlet.ServletWrapper service SRVE0068E: An exception was thrown by one of the service methods of the servlet [/Login.jsp] in application [B2BPortalEAR]. Exception created : [The Struts dispatcher cannot be found.  This is usually caused by using Struts tags without the associated filter. Struts tags are only usable when the request has passed through its servlet filter, which initializes the Struts dispatcher needed for this tag. - [unknown location]
at org.apache.struts2.views.jsp.TagUtils.getStack(TagUtils.java:59)
at org.apache.struts2.views.jsp.StrutsBodyTagSupport.getStack(StrutsBodyTagSupport.java:44)
at org.apache.struts2.views.jsp.ComponentTagSupport.doStartTag(ComponentTagSupport.java:48)
at com.ibm._jsp._Login._jspx_meth_s_text_0(_Login.java:352)
at com.ibm._jsp._Login._jspService(_Login.java:145)
at com.ibm.ws.jsp.runtime.HttpJspBase.service(HttpJspBase.java:99)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1232)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:781)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:480)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at com.ibm.wsspi.webcontainer.servlet.GenericServletWrapper.handleRequest(GenericServletWrapper.java:122)
at com.ibm.ws.jsp.webcontainerext.AbstractJSPExtensionServletWrapper.handleRequest(AbstractJSPExtensionServletWrapper.java:220)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:79)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:967)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1107)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3926)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:304)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1007)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1817)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:463)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:530)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:316)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:287)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1881)
]
LocalTranCoor E   WLTC0017E: Resources rolled back due to setRollbackOnly() being called.
E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[/Login.jsp]: The Struts dispatcher cannot be found.  This is usually caused by using Struts tags without the associated filter. Struts tags are only usable when the request has passed through its servlet filter, which initializes the Struts dispatcher needed for this tag. - [unknown location]
at org.apache.struts2.views.jsp.TagUtils.getStack(TagUtils.java:59)
at org.apache.struts2.views.jsp.StrutsBodyTagSupport.getStack(StrutsBodyTagSupport.java:44)
at org.apache.struts2.views.jsp.ComponentTagSupport.doStartTag(ComponentTagSupport.java:48)
at com.ibm._jsp._Login._jspx_meth_s_text_0(_Login.java:352)
at com.ibm._jsp._Login._jspService(_Login.java:145)
at com.ibm.ws.jsp.runtime.HttpJspBase.service(HttpJspBase.java:99)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1232)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:781)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:480)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl.java:178)
at com.ibm.wsspi.webcontainer.servlet.GenericServletWrapper.handleRequest(GenericServletWrapper.java:122)
at com.ibm.ws.jsp.webcontainerext.AbstractJSPExtensionServletWrapper.handleRequest(AbstractJSPExtensionServletWrapper.java:220)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.invokeTarget(WebAppFilterChain.java:136)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:79)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:967)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1107)
at com.ibm.ws.webcontainer.webapp.WebApp.handleRequest(WebApp.java:3926)
at com.ibm.ws.webcontainer.webapp.WebGroup.handleRequest(WebGroup.java:304)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1007)
at com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1817)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:200)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:463)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:530)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:316)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:287)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1881)
 
Bartender
Posts: 9501
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The error message should cover it:

E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[/Login.jsp]: The Struts dispatcher cannot be found.  This is usually caused by using Struts tags without the associated filter. Struts tags are only usable when the request has passed through its servlet filter, which initializes the Struts dispatcher needed for this tag. - [unknown location] 



Do you have StrutsPrepareAndExecuteFilter in your web.xml?
 
janakiram kota
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Joe Ess wrote:The error message should cover it:

E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[/Login.jsp]: The Struts dispatcher cannot be found.  This is usually caused by using Struts tags without the associated filter. Struts tags are only usable when the request has passed through its servlet filter, which initializes the Struts dispatcher needed for this tag. - [unknown location] 



Do you have StrutsPrepareAndExecuteFilter in your web.xml?


Hello Joe,

Yes i have configured org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter in my web.xml file. Is this the problem if so what i need to configure as dispatcher in my web.xml file can you please advice.

Thanks and Regards,
Janakiram.
 
Bartender
Posts: 19560
90
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Form Based Authorization" usually means Container-Managed Authentication - the J2EE standard security system as configured in WEB-INF/web.xml.

you should not have to change anything between Struts versions or even if you switched from Struts to some other application framework entirely. Because with container-based authentication, it isn't the application program that processes the form, it's the webapp server itself. And because of that, Struts does not process the login. In fact, Struts never even sees the login.

When you use J2EE standard security, an attempt to access a secured URL (one that matches one of the secured URL path patterns in web.xml), the web application server halts the request dead, parks it, sends the login page defined in web.xml to the user, accepts the user's response, checks credentials, and if they don't match, sends out the login-fail page to the user, accepts the user's response and if the credentials don't match, repeats sending the login-fail page until the user submits valid credentials or goes away. If the user enters valid credentials, the original parked URL request is "un-parked" and resumed as though login had never been requested.

As a consequence, you should never attempt to access the login or login-fail pages via a direct URL request, because that won't be properly handled by the server's login services.

Because 100% of the login logic is built into the server and not the application, there's no way for the struts servlet to see the request or process it. For best results and maximum security, a login page should have no struts-specific features on it at all. Otherwise you risk either triggering security exploits or running into problems where you're requesting resources before you're allowed to use them.

Note that this is how things work when you use the J2EE standard container security. If your "form based authorization" is in fact just a do-it-yourself login and it's based on Struts, then it's not going to require any changes that any other web page managed by Struts would. Although I do have to make my standard disclaimer that unless you're a full-time professionally-trained security professional, there's about a 95% chance that your work of genius has a major security hole in it and probably odds of over 75% that it's something that non-technical persons can break through in under 15 minutes. Which is why you should always either use the J2EE standard security, a well-tested security product, or both.
 
Joe Ess
Bartender
Posts: 9501
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

janakiram kota wrote:

Joe Ess wrote:The error message should cover it:

E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[/Login.jsp]: The Struts dispatcher cannot be found.  This is usually caused by using Struts tags without the associated filter. Struts tags are only usable when the request has passed through its servlet filter, which initializes the Struts dispatcher needed for this tag. - [unknown location] 



Do you have StrutsPrepareAndExecuteFilter in your web.xml?


Hello Joe,

Yes i have configured org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter in my web.xml file. Is this the problem if so what i need to configure as dispatcher in my web.xml file can you please advice.

Thanks and Regards,
Janakiram.



If I had to guess, I'd say you are missing the Struts JAR file or one of its dependencies.  What's in WEB-INF/lib?
 
janakiram kota
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:"Form Based Authorization" usually means Container-Managed Authentication - the J2EE standard security system as configured in WEB-INF/web.xml.

You should not have to change anything between Struts versions or even if you switched from Struts to some other application framework entirely. Because with container-based authentication, it isn't the application program that processes the form, it's the webapp server itself. And because of that, Struts does not process the login. In fact, Struts never even sees the login.

When you use J2EE standard security, an attempt to access a secured URL (one that matches one of the secured URL path patterns in web.xml), the web application server halts the request dead, parks it, sends the login page defined in web.xml to the user, accepts the user's response, checks credentials, and if they don't match, sends out the login-fail page to the user, accepts the user's response and if the credentials don't match, repeats sending the login-fail page until the user submits valid credentials or goes away. If the user enters valid credentials, the original parked URL request is "un-parked" and resumed as though login had never been requested.

As a consequence, you should never attempt to access the login or login-fail pages via a direct URL request, because that won't be properly handled by the server's login services.

Because 100% of the login logic is built into the server and not the application, there's no way for the struts servlet to see the request or process it. For best results and maximum security, a login page should have no struts-specific features on it at all. Otherwise you risk either triggering security exploits or running into problems where you're requesting resources before you're allowed to use them.

Note that this is how things work when you use the J2EE standard container security. If your "form based authorization" is in fact just a do-it-yourself login and it's based on Struts, then it's not going to require any changes that any other web page managed by Struts would. Although I do have to make my standard disclaimer that unless you're a full-time professionally-trained security professional, there's about a 95% chance that your work of genius has a major security hole in it and probably odds of over 75% that it's something that non-technical persons can break through in under 15 minutes. Which is why you should always either use the J2EE standard security, a well-tested security product, or both.



Thanks a lot Tim for your detailed explanation.

What i am trying to do is as part of migration from Struts 1 to Struts 2.5 I have added a filter mappings in web.xml and I commented the servlet mapping section which was already existing in web.xml file.

Now after the changes done i was trying to access my login page i got this issue. When i have checked the action that was been defined in Login page i could able to see

<form name="form1" method="post" action="j_security_check">

Can you please advise do i need to do anything more on this meaning do i need to create any action class and define the same in struts.xml something like this please advice.

Thanks and Regards,
Janakiram.

 
janakiram kota
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Joe Ess wrote:

janakiram kota wrote:

Joe Ess wrote:The error message should cover it:

E com.ibm.ws.webcontainer.webapp.WebApp logServletError SRVE0293E: [Servlet Error]-[/Login.jsp]: The Struts dispatcher cannot be found.  This is usually caused by using Struts tags without the associated filter. Struts tags are only usable when the request has passed through its servlet filter, which initializes the Struts dispatcher needed for this tag. - [unknown location] 



Do you have StrutsPrepareAndExecuteFilter in your web.xml?


Hello Joe,

Yes i have configured org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter in my web.xml file. Is this the problem if so what i need to configure as dispatcher in my web.xml file can you please advice.

Thanks and Regards,
Janakiram.



If I had to guess, I'd say you are missing the Struts JAR file or one of its dependencies.  What's in WEB-INF/lib?



Hello Joe,

Below were the Jar that i have in WEB-INF/lib folder

1. commons-beanutils-1.8.0.jar
2. commons-digester-2.0.jar
3. commons-fileupload-1.3.3.jar
4. commons-io-2.5.jar
5. commons-lang3-3.6.jar
6. freemarker-2.3.23.jar
7. javassist-3.7.ga.jar
8. jcl-over-slf4j-1.7.6.jar
9. log4j-api-2.8.2.jar
10. slf4j-api-1.7.6.jar
11. struts2-core-2.5.13.jar
12. struts2-tiles-plugin-2.5.13.jar
13. tiles-api-3.0.7.jar
14. tiles-autotag-core-runtime-1.2.jar
15. tiles-core-3.0.7.jar
16. tiles-el-3.0.7.jar
17. tiles-freemarker-3.0.7.jar
18. tiles-jsp-3.0.7.jar
19. tiles-ognl-3.0.7.jar
20. tiles-request-api-1.0.6.jar
21. tiles-request-freemarker-1.0.6.jar
22. tiles-request-jsp-1.0.6.jar
23. tiles-request-servlet-1.0.6.jar
24. tiles-servlet-3.0.7.jar
25. tiles-template-3.0.7.jar
26. commons-beanutils.jar
27. commons-collections.jar
28. commons-digester.jar
29. commons-fileupload.jar
30. commons-lang.jar
31. commons-logging.jar
32. commons-validator.jar
33. jakarta-oro.jar
34. struts.jar
35. ognl-3.1.15.jar
36. commons-logging-1.1.3.jar
37. asm-tree-3.3.jar
38. asm-commons-3.3.jar
39. asm-3.3.jar
40. log4j-1.2.14.jar

Still we have some other pages which were running in Struts 1 so i have maintained the Old Jar files in lib folder.

Please let me know if i have missed any Jar's so that i can add to lib folder.

Thanks and Regards,
Janakiram.
 
Tim Holloway
Bartender
Posts: 19560
90
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The "j_security_check" is the key. The only thing you have to do is produce an HTML or JSP page containing a form whose action is "j_security_check" and has the j_username and j_password controls on it.

As I said before, you never request this page yourself. It is automatically displayed when a user needs to be authenticated. The server knows that to do without any help.

The server also is responsible for checking the username/password against whatever security database ("Realm") you've defined as part of the server configuration. Again, no application logic is written.

The login doesn't know or care that the application is a Struts application and works exactly the same whether it's Struts 1, Struts 2, JavaServer Faces, or even just brute-force servlets and JSPs. You don't write code, you don't have to include any special JARs in the WEB-INF/lib directory. Everything is already written, debugged and installed in the server except for the login and loginfail form page templates and the security rules in web.xml.

Because the security is external to the application, bad requests can be bounced before they can get in and exploit the application and you can change your credentials "database" without making modifications to the application. You can keep the credentials in a file, a JDBC database, an LDAP/Active Directory server, or even use a single-signon manager with no changes.
 
Joe Ess
Bartender
Posts: 9501
12
Linux Mac OS X Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

janakiram kota wrote:
Please let me know if i have missed any Jar's so that i can add to lib folder.



I don't see any obvious omissions.  Struts 1 and 2 supposedly can play nice together (see here) but I've never tried it.
Is the URL you are trying to load the JSP or the action?  If you try to load the JSP directly, that will bypass the Struts filter and cause the error you are having.
 
janakiram kota
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Holloway wrote:The "j_security_check" is the key. The only thing you have to do is produce an HTML or JSP page containing a form whose action is "j_security_check" and has the j_username and j_password controls on it.

As I said before, you never request this page yourself. It is automatically displayed when a user needs to be authenticated. The server knows that to do without any help.

The server also is responsible for checking the username/password against whatever security database ("Realm") you've defined as part of the server configuration. Again, no application logic is written.

The login doesn't know or care that the application is a Struts application and works exactly the same whether it's Struts 1, Struts 2, JavaServer Faces, or even just brute-force servlets and JSPs. You don't write code, you don't have to include any special JARs in the WEB-INF/lib directory. Everything is already written, debugged and installed in the server except for the login and loginfail form page templates and the security rules in web.xml.

Because the security is external to the application, bad requests can be bounced before they can get in and exploit the application and you can change your credentials "database" without making modifications to the application. You can keep the credentials in a file, a JDBC database, an LDAP/Active Directory server, or even use a single-signon manager with no changes.



Thanks once Tim for your explanation. I am done with the migration.

Thanks and Regards,
Janakiram.
 
crispy bacon. crispy tiny ad:
Why should you try IntelliJ IDEA ?
https://coderanch.com/wiki/696337/IntelliJ-IDEA
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!