>Your approach is ok but I cannot apply it because I have to use container
>managed authentication. And to be onest I want to use declarative
>security/transaction/persistence so I can concentrate on the project not on
>the infrastructure (this is the j2ee server's job, isn't it ?).
>

With a little work you can make the filter use the container's security. 
Just replace the getSession(USER_SIGNED_ON_SESSION_KEY)!=null with 
request.getUser()!=null ... and make the login page your container's form 
login page ....

>The actions in webwork are not tight to the url  -
>http://host/do_smth.action is the same with http://host/dir/do_smth.action 
>.
>I think this is because they are designed to exist not only in web app but
>in a client app too.
>

WebWork is technology agnostic... It can be used from a servlet, client and 
a friend of mine even made a dispatcher to execute WebWork actions from 
IIS/ASP through a J++ COM Dispatcher... This flexibility gives you a lot of 
power but comes at a price.

>What I need is an extra piece of information that will define where the
>action can exist. Somthing like:
>
>     <action name="ModifyAccount" alias="modify_account">
>         <available-in>/customer</available-in>
>         <view name="success">account.jsp</view>
>     </action>
>

This can easily be factored in ServletDispatcher. In fact, you could modify 
the filter to not do login logic, read the "available-in" tag and compare 
that with the request, if it doesn't match then send a 404 error.

>This will solve all my security problems but this seems to break the
>generality of webwork.
>
>Anyway, it pretty frustrating that the only way to use webwork in a secure
>app is to create your own login module.
>

There are many ways to secure a Webwork application. One of them is to have 
a base Action that overrides "execute" and checks your security logic there 
(e.g. request.getUser() ) and if the user is not logged on returns LOGIN, 
which would be mapped to your form login page.... and if the user is already 
authenticated calls super.execute() so the flow continues.

WebWork is extremely flexible in this area and I hope that you don't become 
disappointed as there are efficient ways to do what you need in WebWork.

The design philosophy behind WebWork is that small is better, otherwise we'd 
have Struts or Turbine all over again. These packages make you do things 
their way which might not always be how you want them. WebWork gives you the 
opportunity to at least have all that control and do it the way you want.

I understand this might seem overwhelming at first, but it's great... you'll 
see soon enough.

After 1.0 is released we'll setup a best practices toolset to allow for all 
these "additions".

Cheers,

Victor Salaman



_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com


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

Reply via email to