Re: Struts Application Security within the Controller Layer
What errorthat looks like the normal startup messages of tomcat to me. Nathan On Apr 18, 2004, at 6:15 AM, [EMAIL PROTECTED] wrote: Hi All, I have installed Tomcat server on my machine and tried to start it using startup.bat im getting following error C:\Tomcat\catalina\src\bin>startup Using CATALINA_BASE: C:\Tomcat\catalina\src Using CATALINA_HOME: C:\Tomcat\catalina\src Using CATALINA_TMPDIR: C:\Tomcat\catalina\src\temp Using JAVA_HOME: C:\jdk1.3.1_11 C:\Tomcat\catalina\src\bin> can anyone help me !!this will be very useful to me thanks rgds Birendar Singh Waldiya - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Application Security within the Controller Layer
Hi All, I have installed Tomcat server on my machine and tried to start it using startup.bat im getting following error C:\Tomcat\catalina\src\bin>startup Using CATALINA_BASE: C:\Tomcat\catalina\src Using CATALINA_HOME: C:\Tomcat\catalina\src Using CATALINA_TMPDIR: C:\Tomcat\catalina\src\temp Using JAVA_HOME: C:\jdk1.3.1_11 C:\Tomcat\catalina\src\bin> can anyone help me !!this will be very useful to me thanks rgds Birendar Singh Waldiya DISCLAIMER: The information contained in this message is intended only and solely for the addressed individual or entity indicated in this message and for the exclusive use of the said addressed individual or entity indicated in this message (or responsible for delivery of the message to such person) and may contain legally privileged and confidential information belonging to Tata Consultancy Services. It must not be printed, read, copied, disclosed, forwarded, distributed or used (in whatsoever manner) by any person other than the addressee. Unauthorized use, disclosure or copying is strictly prohibited and may constitute unlawful act and can possibly attract legal action, civil and/or criminal. The contents of this message need not necessarily reflect or endorse the views of Tata Consultancy Services on any subject matter. Any action taken or omitted to be taken based on this message is entirely at your risk and neither the originator of this message nor Tata Consultancy Services takes any responsibility or liability towards the same. Opinions, conclusions and any other information contained in this message that do not relate to the official business of Tata Consultancy Services shall be understood as neither given nor endorsed by Tata Consultancy Services or any affiliate of Tata Consultancy Services. If you have received this message in error, you should destroy this message and may please notify the sender by e-mail. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Application Security within the Controller Layer
Joe, Your suggestion sounds interesting, but I'm not sure if I fully understand it. Correct me if I'm wrong. You suggest extending the ActionMapping class and adding the fields to this class that I will need for checking the user group that may access this path/resource. Let's say this is a simple application, and there is an integer or string that is stored, identifying the access level to this resource. So, when this class is built, would it represent an action within my struts config file, and with the changes permit me to somehow specify the permission level that has access to the action? I'm a little confused about the "SecureActionMapping" interface you mentioned. However, if what you are suggesting is that the extended ActionMapping would now contain the role that has access to this action, I could then extend the RequestProcessor to inspect the permitted user group that is stored in the new ActionMapping class, and compare it to the permission level stored in the User's session. If these don't agree with one another, the user does not have access to the path/resource, and will be directed to an error page. Is this what you had in mind? If so, I'm still a little confused about how to extend the ActionMapping so it would contain the correct permission level info for access to the resource. How/where would this information be configured. I think you might be suggesting additional XML elements or attributes may be added to the Action element in the StrutsConfig file, but I'm not sure. Please let me know your thoughts. Everyone else is also free to comment. Regards, Josh -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Friday, April 16, 2004 9:07 AM To: Struts Users Mailing List Subject: RE: Struts Application Security within the Controller Layer The way to configure this flexibly for each action would be to define an extension of ActionMapping that was a bean with whatever config properties you need (for instance, a role or list of roles permitted to access the action.) Of course, since each path gets only one ActionMapping, you may need to use a "SecureActionMapping" interface that you could implement with various mapping classes. (It seems to take Struts users a while to get into the idea of using ActionMapping to provide extended configuration information to an Action class, but it can be a very nice way to avoid re-coding the same logic over and over.) Once you have this, you could either find another spot in the request processor to enforce this logic (very easy with a chainable processor, of course), or use a "SecureAction" base class from which you extend for any paths which must be controlled, which would do authorization before passing control to the subclass. Joe >I'll look into the "ComposableRequestProcessor" for future projects. This >seems like it could be a very powerful feature, if used correctly. > >Since we are on the subject of Control and security, let me throw in another >question. > >My application has three different user permission levels. >1) User >3) Super User >2) Admin > >Each account in the DATABASE is classified with one of these permission >levels. > >I want to also inspect each request before an Action is dispatched to >confirm that the User should be granted access to execute the Action. > >At first thought, it seems that I cannot use the processRoles() feature of >the RequestProcessor, because my permission levels are not stored into the >config file, but rather in the database. Or should I say, I cannot take >this approach without overriding this method (which may be a solid >approach.. but I haven't thought it out much. I imagine this would require a >way for me to map each action with the correct access groups). > >I could put this logic into each Action class, but, for obvious reasons, >this will be a maintenance nightmare. > >Can anyone offer any suggestions on these or other approaches? > >Your assistance is greatly appreciated as it always is. -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Application Security within the Controller Layer
You don't need to add "additional XML elements to the Action in the
struts-config.xml" to use a custom ActionMapping
If you create your own custom ActionMapping with an additional
"securityLevel" property:
public class MyActionMapping extends ActionMapping {
protected String securityLevel;
public void setSecurityLevel(String securityLevel) {
this.securityLevel = securityLevel;
}
public String getSecurityLevel() {
return securityLevel;
}
}
The in your struts-config.xml you can configure struts to use your custom
mapping using the type on the element and set the new
attribute for one of your actions using :
Niall
- Original Message -
From: "Josh Holtzman" <[EMAIL PROTECTED]>
To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]>
Sent: Saturday, April 17, 2004 10:41 PM
Subject: RE: Struts Application Security within the Controller Layer
> Joe,
>
> Your suggestion sounds interesting, but I'm not sure if I fully understand
> it.
>
> Correct me if I'm wrong.
>
> You suggest extending the ActionMapping class and adding the fields to
this
> class that I will need for checking the user group that may access this
> path/resource. Let's say this is a simple application, and there is an
> integer or string that is stored, identifying the access level to this
> resource. So, when this class is built, would it represent an action
within
> my struts config file, and with the changes permit me to somehow specify
the
> permission level that has access to the action?
>
> I'm a little confused about the "SecureActionMapping" interface you
> mentioned.
>
> However, if what you are suggesting is that the extended ActionMapping
would
> now contain the role that has access to this action, I could then extend
the
> RequestProcessor to inspect the permitted user group that is stored in the
> new ActionMapping class, and compare it to the permission level stored in
> the User's session. If these don't agree with one another, the user does
> not have access to the path/resource, and will be directed to an error
page.
>
> Is this what you had in mind? If so, I'm still a little confused about
how
> to extend the ActionMapping so it would contain the correct permission
level
> info for access to the resource. How/where would this information be
> configured. I think you might be suggesting additional XML elements or
> attributes may be added to the Action element in the StrutsConfig file,
but
> I'm not sure.
>
> Please let me know your thoughts. Everyone else is also free to comment.
>
> Regards,
>
> Josh
>
> -Original Message-
> From: Joe Germuska [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 16, 2004 9:07 AM
> To: Struts Users Mailing List
> Subject: RE: Struts Application Security within the Controller Layer
>
> The way to configure this flexibly for each action would be to define
> an extension of ActionMapping that was a bean with whatever config
> properties you need (for instance, a role or list of roles permitted
> to access the action.) Of course, since each path gets only one
> ActionMapping, you may need to use a "SecureActionMapping" interface
> that you could implement with various mapping classes. (It seems to
> take Struts users a while to get into the idea of using ActionMapping
> to provide extended configuration information to an Action class, but
> it can be a very nice way to avoid re-coding the same logic over and
> over.)
>
> Once you have this, you could either find another spot in the request
> processor to enforce this logic (very easy with a chainable
> processor, of course), or use a "SecureAction" base class from which
> you extend for any paths which must be controlled, which would do
> authorization before passing control to the subclass.
>
> Joe
>
>
> >I'll look into the "ComposableRequestProcessor" for future projects.
This
> >seems like it could be a very powerful feature, if used correctly.
> >
> >Since we are on the subject of Control and security, let me throw in
> another
> >question.
> >
> >My application has three different user permission levels.
> >1) User
> >3) Super User
> >2) Admin
> >
> >Each account in the DATABASE is classified with one of these permission
> >levels.
> >
> >I want to also inspect each request before an Action is dispatched to
> >confirm that the User should be granted access to execute the Action.
> >
> >At first thought, it seems that I cannot use the processRoles() feature
of
> >the RequestProcessor, becau
RE: Struts Application Security within the Controller Layer
The way to configure this flexibly for each action would be to define an extension of ActionMapping that was a bean with whatever config properties you need (for instance, a role or list of roles permitted to access the action.) Of course, since each path gets only one ActionMapping, you may need to use a "SecureActionMapping" interface that you could implement with various mapping classes. (It seems to take Struts users a while to get into the idea of using ActionMapping to provide extended configuration information to an Action class, but it can be a very nice way to avoid re-coding the same logic over and over.) Once you have this, you could either find another spot in the request processor to enforce this logic (very easy with a chainable processor, of course), or use a "SecureAction" base class from which you extend for any paths which must be controlled, which would do authorization before passing control to the subclass. Joe I'll look into the "ComposableRequestProcessor" for future projects. This seems like it could be a very powerful feature, if used correctly. Since we are on the subject of Control and security, let me throw in another question. My application has three different user permission levels. 1) User 3) Super User 2) Admin Each account in the DATABASE is classified with one of these permission levels. I want to also inspect each request before an Action is dispatched to confirm that the User should be granted access to execute the Action. At first thought, it seems that I cannot use the processRoles() feature of the RequestProcessor, because my permission levels are not stored into the config file, but rather in the database. Or should I say, I cannot take this approach without overriding this method (which may be a solid approach.. but I haven't thought it out much. I imagine this would require a way for me to map each action with the correct access groups). I could put this logic into each Action class, but, for obvious reasons, this will be a maintenance nightmare. Can anyone offer any suggestions on these or other approaches? Your assistance is greatly appreciated as it always is. -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Application Security within the Controller Layer
If your container supports servlet 2.3, use a filter. That's really the best place for a check like that. Jason Josh Holtzman wrote: Hello all, I'm working on a Struts application that contains 2 modules. Module 1 (default): a public website. Module 2: a user and administrative login. Module 2 obviously needs to be secure. To secure Module 2 I intend to build 2 measures into take the following steps: a) Before any action is executed check that the user is logged in by looking for a "User" object in the session. b) check that all connections are via the https protocol. In the event that either of these checks fail, the user is redirected to an error page. As a novice, but rapidly learning, Struts developer, I believe the logical place to put these checks is to subclass the RequestProcessor and override the processPreprocess() method with this logic? An immediate alternative that comes to mind is to create a base action that would handle this logic, however, I don't think that is where this belongs in a Struts application. simply if the request doesn't meet the requirements stated above, the User shouldn't get to the Action in the first place. Does anyone have any suggestions or best practices they can offer? Thanks. Josh Holtzman American Data Company [EMAIL PROTECTED] Voice: (310) 470-1257 Fax:(310) 362-8454 Sun Microsystems iForce Partner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Application Security within the Controller Layer
Josh Holtzman wrote: Module 2 obviously needs to be secure. To secure Module 2 I intend to build 2 measures into take the following steps: a) Before any action is executed check that the user is logged in by looking for a "User" object in the session. b) check that all connections are via the https protocol. In the event that either of these checks fail, the user is redirected to an error page. Josh, this would appear to be a good place to use a ServletFilter. Since your checks are for Module 2 it is a simple mapping for the filter. Also, the two checks you described do not rely on Struts itself. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Struts Application Security within the Controller Layer
Thanks Joe. I'll look into the "ComposableRequestProcessor" for future projects. This seems like it could be a very powerful feature, if used correctly. Since we are on the subject of Control and security, let me throw in another question. My application has three different user permission levels. 1) User 3) Super User 2) Admin Each account in the DATABASE is classified with one of these permission levels. I want to also inspect each request before an Action is dispatched to confirm that the User should be granted access to execute the Action. At first thought, it seems that I cannot use the processRoles() feature of the RequestProcessor, because my permission levels are not stored into the config file, but rather in the database. Or should I say, I cannot take this approach without overriding this method (which may be a solid approach.. but I haven't thought it out much. I imagine this would require a way for me to map each action with the correct access groups). I could put this logic into each Action class, but, for obvious reasons, this will be a maintenance nightmare. Can anyone offer any suggestions on these or other approaches? Your assistance is greatly appreciated as it always is. Regards, Josh Holtzman American Data Company [EMAIL PROTECTED] Voice: (310) 470-1257 Fax:(310) 362-8454 Sun Microsystems iForce Partner -Original Message- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Thursday, April 15, 2004 11:31 AM To: Struts Users Mailing List Subject: Re: Struts Application Security within the Controller Layer >As a novice, but rapidly learning, Struts developer, I believe the logical >place to put these checks is to subclass the RequestProcessor and override >the processPreprocess() method with this logic? I think your analysis is right on; it's not *wrong* to implement the security with a base abstract action, but when you do that, you lose your single inheritance (and incur some probably trivial extra overhead by performing more of the request processing cycle before stopping.) However, for a simple app or quick proof-of-concept, this is sometimes a good way. Also, extending RequestProcessor can be mildly problematic if you have a few different kinds of changes you want to make to the request-processing life-cycle (again because of the limitation to single inheritance). You may be interested in experimenting with the (beta-quality) struts-chain package and it's "ComposableRequestProcessor", which allows you to define an arbitrary chain of commands for handling a request (and provides a default chain which recreates the standard RequestProcessor behavior.) As soon as Struts 1.2.1 is released (Real Soon Now), we'll begin the process of converting the Struts core to use the chain request processor.I think that developers will find it very empowering to have fine control over the entire request processing life cycle, rather than only ever writing actions. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Struts Application Security within the Controller Layer
As a novice, but rapidly learning, Struts developer, I believe the logical place to put these checks is to subclass the RequestProcessor and override the processPreprocess() method with this logic? I think your analysis is right on; it's not *wrong* to implement the security with a base abstract action, but when you do that, you lose your single inheritance (and incur some probably trivial extra overhead by performing more of the request processing cycle before stopping.) However, for a simple app or quick proof-of-concept, this is sometimes a good way. Also, extending RequestProcessor can be mildly problematic if you have a few different kinds of changes you want to make to the request-processing life-cycle (again because of the limitation to single inheritance). You may be interested in experimenting with the (beta-quality) struts-chain package and it's "ComposableRequestProcessor", which allows you to define an arbitrary chain of commands for handling a request (and provides a default chain which recreates the standard RequestProcessor behavior.) As soon as Struts 1.2.1 is released (Real Soon Now), we'll begin the process of converting the Struts core to use the chain request processor.I think that developers will find it very empowering to have fine control over the entire request processing life cycle, rather than only ever writing actions. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining." -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
