Announcement Announcement Module
Collapse
No announcement yet.
Not reaching Struts Action Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Not reaching Struts Action

    I'm using the InMemory implementation for the moment. I mapped the ActionForm (I cheated I named the fields j_username and j_password, I think this should not be hardcoded as a static String but should be set like that by default and add setters to change them). What is strange is that I'm not reaching the struts action (I put a breakpoint on the execute method).

    When I do this:
    Code:
    <bean id="authenticationProcessingFilter" class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
        <property name="authenticationManager">
          <ref bean="authenticationManager"/>
        </property>
        <property name="authenticationFailureUrl">
          <value>/Login.do</value>
        </property>
        <property name="defaultTargetUrl">
          <value>/Welcome.do</value>
        </property>
        <property name="filterProcessesUrl">
          <value>/LoginSubmit.do</value>
        </property>
        <property name="rememberMeServices">
          <ref local="rememberMeServices"/>
        </property>
      </bean>
    I end up on the welcome page where I've put some tags like <authz:authorize ifAllGranted="ROLE_S"> and I actually can see that the principal has the role. So I put the /LoginSubmit.do in the defaultTargetUrl but that ends up back to the login page giving me the error Bad credentials presented and indicating the user is anonymous (using the taglib). Am I doing something wrong?

  • #2
    Anyone?

    Comment


    • #3
      Just curious why you are mapping the following:

      Code:
          <property name="filterProcessesUrl"> 
            <value>/LoginSubmit.do</value> 
          </property>
      The authentication processing filter to look for URL requests that match 'LoginSubmit.do' and trigger a login request.

      Normally this is set to j_acegi_security_check.

      If the user is not logged in, then it will forward to the authenticationFailureUrl.

      Why are you trying to call a Struts action upon logon? The Acegi framework will perform the authentication.. so you shouldnt have to do anything programatically in a Struts action... (if that is what you are doing?)

      Basically, I am curious what you are using the struts action for?
      If you need to do special processing you can also hook into the ApplicationEvent model to listen for particular events (success login, failure, etc.)

      Cheers
      Mark

      Comment


      • #4
        Hi,
        thanks for the interest. The LoginAction that I had that is mapped on the LoginSubmit.so url basicly did 2 things. It used a business delegate to access the EJB module, it recuperates a UserDTO object that encapsulates the user data that I used to access for example the roles, name, address etc. and eventual errors or warnings that might have happened along the way and puts it in the session. This is the first thing, and it's binded to the application logic, the second thing is that I use struts mapping to know where do I have to finish, on the "success" or "failure" target. This is the second part of the thing and it's what I'd say it's a controller's job.
        That said I'd like to give my 2 cents but I'm not criticizing Ben as he's doing a fantastic framework. If I'm wrong please correct me.
        What I think is that the default processing filter is ok but it handles both aspects of the job and I think this is wrong. To me a filter should be transparent and shouldn't be always hardwired where it should finish on success or failure as I thing this is a responsability for a controller. He should process the fields (perhaps not hardwired to j_username and j_password ) and apply the credential to the request. The logic that was applyed in creating this filter effectively makes it difficult to blend well with MVC frameworks like struts (at least this is my experience). This makes the gathering of internals errors to display to the end user using the ActionMessages difficult (ex. I don't have the auxilary method that a struts Action has to save the errors so that they persist in the request). That is why I was using the LoginSubmit.do as the url to map. I've passed and reimplemented the filter processor hovever I don't know what to do with the errors (see other post).
        I'd suggest Ben to implement a filter that doesn't handle the controller part and allow passing through to the controller url thus allowing the end programmer to use all the benefits of the framework he/she uses. That said, I might be wrong.

        Comment


        • #5
          Hi,

          I also use struts and I'm not sure if I understand your concerns. By using "extends AuthenticationProcessingFilter" you can have your username and password keys be anything you want.

          Furthermore, by throwing BadCredentialsException you can have your errors along with session.getAttribute(AbstractProcessingFilter.ACEG I_SECURITY_LAST_EXCEPTION_KEY)).getMessage(), and via a custom UserDetails you can put any other info you need in the session.

          Lastly, I personally like the idea of skipping over the mvc frameworks entirely but that's just a matter of style.

          Cheers,
          iksrazal

          Comment


          • #6
            Thanks for your thoughts, could you paste your authenticationProcessingFilter bean, how you extended AuthenticationProcessingFilter? Where do you throw your BadCredentialsException and I'm sorry but I haven't reached UserDetails yet.
            PS. Can u use the acegi roles in the roles attribute of the struts-config file <action> tags?

            Comment


            • #7
              You could do all your EJB and DTO management inside the AuthenticationDao that backs your DaoAuthenticationProvider.

              In connection with the design of AuthenticationProcessingFilter, I intentionally was trying to be framework independent AND as close as possible to the behaviour of servlet spec (container) security. That way people can easily understand it. Logical separation of MVC controller, view and processing logic is achieved via the filter, URLs on success/failure and AuthenticationProvider respectively. I believe the model is reasonable. If localisation of messages is a major issue, you can deal with that in your view. If you need different MVC workflow after a successful login or failed login, you can have the URL that AuthenticationProcessingFilter redirects to map to a true Controller where that can be achieved. You can also extend AuthenticationProcessingFilter.

              I discourage people writing their own authentication mechanism (which is the term to describe any XXXXXProcessingFilter) because there are often problems implementing the correct behaviour. There's nothing fundamentally complicated about the behaviour, it's just the framework itself ought to be sufficient to address 95% of requirements. Even the DTO / EJB requirement and localisation is satisfactory addressed without writing your own authentication mechanism in a Struts Action, as far as I can see.

              Comment


              • #8
                Actually in the end (before I decided to try use an adapter) I did just that, see my post Struts and roles.

                Comment

                Working...
                X