Hi Bogdan:
That works, but it is painful in the event of changes in business
requirements. Let's say that you work for a widget store, and your boss
tells you to implement a knowledge base system, and you do. You make a lot
of pages that have context sensitive links to those pages. Let's say 50 in
total ....
Now 6 months down the line, the business needs change, now you need to start
charging for knowledge base access. So you need to protect those resources.
Although your approach would work perfectly fine, in this event it would
require you to change all your links to these pages from .action to .saction
... Not only is this tedious, it is error prone.
You should be able to protect a resource, transparently to the protected
actions... That's why I wrote that filter... As I said, I don't really know
if this was useful to you or anyone, but it was useful to me :)
/V
>From: "Bogdan Ghidireac" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Subject: Re: [Webwork-user] Secured actions
>Date: Sat, 9 Feb 2002 14:20:00 +0200
>
>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
_________________________________________________________________
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
