So it looks like there is no standard way. I would like to propose a
different approach (based on Victor's) that requires some changes in the
webwork source code.

First, add a new mapping to web.xml. This way all ".s_action" urls will be
protected by the container.
   ......
    <servlet-mapping>
        <servlet-name>action</servlet-name>
        <url-pattern>*.action</url-pattern>
    </servlet-mapping>
    <servlet-mapping>
        <servlet-name>action</servlet-name>
        <url-pattern>*.s_action</url-pattern>
    </servlet-mapping>
   .....
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Protected Area</web-resource-name>
            <description>Protected Area</description>
            <url-pattern>*.s_action</url-pattern>
            <http-method>HEAD</http-method>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
            <http-method>PUT</http-method>
            <http-method>DELETE</http-method>
        </web-resource-collection>
        .......
    </security-constraint>


Then webwork.config.XMLActionConfiguration should be modified to read the
new "login-required" attribute and to map the actions to ".action" or to
".s_action" depending on the "login-required" flag.

I am new to webwork so please excuse me if this is a nonsense :)

Regards,
Bogdan

----- Original Message -----
From: "Victor Salaman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, February 09, 2002 2:49 AM
Subject: Re: [Webwork-user] Secured actions


> I wrote such a beat a little while back. WARNING: Danger ahead :)
>
> Anyways, it works the following way... you need to use the xml action
> configuration (e.g. actions.xml). For any resource you want to protect,
just
> stick the attribute login-required='true' ... This works for action names
> and aliases.
>
> This filter has two dependencies:
>
> exml.jar (www.themindelectric.com) -- Or modify to use whatever parser you
> like.
>
> log4j.jar
>
> and of course servlet.jar , but that's obvious!
>
> The filter is configured with two defs in the file webwork.properties:
>
> signon.filter.action-extension=action
> signon.filter.login-page=/login.action
>
> This assumes you have an action aliased to "login" .... you can change
> signon.filter.login-page if you want to call it something else.
>
> The filter initializes itself and adds the restrictions to its
configuration
> upon startup. Upon receiving a request, the filter will examine it,
compare
> it to its configuration and decide if to let it through or forward the
> request to the LOGIN page.
>
> The mechanism to check wether a user is logged on is by checking that a
> non-null value exist in session attribute pointed by
> SIGNED_ON_USER_SESSION_KEY (you need to change this in your source, as my
> Constants.java has a lot of constants unrelated to this -- or add your own
> Constants.java)
>
> Upon forwarding the request to the LOGIN page, the filter will set a
session
> attribute of ORIGINAL_URL_SESSION_KEY so your action can pick up right
where
> it left off by doing a
>
request.getRequestDispatcher(session.getAttribute(ORIGINAL_URL_SESSION_KEY))
.forward(request,response)
> if the user is authenticated properly .....
>
> If the user is already logged on, the resource is served.
>
> ---
>
> NOTES:
>
> 1. Using this approach: login and access control is done in the
login.action
> so all the logic is there.
>
> 2. Upon processing the LoginAction.java (your  action) should always
remove
> ORIGINAL_URL_SESSION_KEY from the session's attributes.
>
> ----
>
> I would have committed this and many other interesting things, but I don't
> want to affect the upcoming release. After this, we'll implement a
test-area
> where all these toys can be published.
>
> /V
>
> P.S. Your login action should have a segment that looks something like:
>
>          User user = findUser(userName);
>
>          if(user == null)
>          {
>             addErrorMessage(getText("invalid_login"));
>             return ERROR;
>          }
>
>          if(authenticate(user, password))
>          {
>             makeUserValidAndForward(user);
>             return SUCESS;
>          }
>          else
>          {
>             session.remove(SIGNED_ON_USER_SESSION_KEY);
>             addErrorMessage(getText("invalid_login"));
>             return ERROR;
>          }
>
> Filter definitions in web.xml look like:
>
> <filter>
> <filter-name>signon</filter-name>
>
<filter-class>com.qoretech.anubis.web.filter.security.SignOnFilter</filter-c
lass>
> </filter>
>
> <filter-mapping>
> <filter-name>signon</filter-name>
> <url-pattern>/*</url-pattern>
> </filter-mapping>
>
> Enjoy.
>
> (I know I should have answered this in webwork-devel , but you asked in
> webwork-user ... so sorry to all the poor souls who received my ramblings
on
> a friday night)
>
>
> >From: "Bogdan Ghidireac" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Subject: [Webwork-user] Secured actions
> >Date: Sat, 9 Feb 2002 00:42:05 +0200
> >
> >Hi,
> >
> >I have a web app that is using container managed authentication. All the
> >files from /customer directory are protected.
> >
> >Also I have a set of actions that are related to the secured domain
> >(example: modify_account.action). What I want to do is to include these
> >actions into the security domain so they can be executed only by
> >authenticated users.
> >
> >Right now it is working if my url looks like
> >http://host/customer/modify_account.action but if the url is modified to
> >http://host/modify_account.action then the action is also executed.
> >
> >Regards,
> >Bogdan
> >
> >
> >
> >
> >_______________________________________________
> >Webwork-user mailing list
> >[EMAIL PROTECTED]
> >https://lists.sourceforge.net/lists/listinfo/webwork-user
>
>
>
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at
http://explorer.msn.com/intl.asp.
>


_______________________________________________
Webwork-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webwork-user

Reply via email to