Is there any particular reason why custom logins are not favored over using this sort of approach? They seem to be capable of more fine tuned access control and can easily be relegated to a common solution for different needs.
On 5/9/05, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 5/9/05, Jeff Beal <[EMAIL PROTECTED]> wrote: > > Solution 1: I don't believe there has to be any correlation between > > your web-resource-collections in your security-constraints and your > > servlet-mappings in web.xml. It seems to be perfectly valid to map > > *.do to ActionServlet (a single servlet-mapping) and have /admin/*.do > > and /user/*.do handled by two different security constraints. > > There's an important detail necessary to get this right. > > URL patterns in web.xml are not fully flexible regular expressions. > What you would do in this case is map Struts to "*.do", and have web > resource collection constraints on "/admin/*" and "/user/*". That > would have the effect of protecting the admin and user actions (as > well as anything else in those two subdirectories), while allowing > unauthenticated access to all the other actions. > > > > > Solution 2: You also have the option (since Struts 1.1) to declare > > your security inside of struts-config.xml. The roles attribute of the > > action element lists the set of roles that you are allowing to access > > a particular action. > > This is likely to be better if you want to protect just a few actions, > instead of groups of them. In the latter case, Solution 1 is likely > to work better. > > > > > -- Jeff > > > > Craig > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
