Re: JDBC driver specific functionality/GenericConnections
Hello, I would like to access functionality specific to the MM MySql driver in an application that uses Struts' datasource pool and am having a bit of troubling casting a GenericConnection back to an org.gjt.mm.mysql.Connection. Casting from a GenericConnection to an org.gjt.mm.mysql.Connection results in a class cast exception; casting a Statement or PreparedStatement generated by the GenericConnection produces a null pointer exception. I am working with Struts 1.0-beta-1 and MM Mysql 2.0.4. If it sheds any light on the problem, the MM function I would like to access is PreparedStatement.getLastInsertID(). Has anyone successfully prosecuted this? You must not cast GenericConnection to What you really want to do is call DataSource.getConnection which returns a Connection object like so: DataSource ds = getServlet().findDataSource(null); Connection con = ds.getConnection(); You can cast this connection to org.gjt.mm.mysql.Connection without any problems! On a tangential note--why is the getConnection() method in GenericConnection private? Were it public, I assume I could use it to get an MM Connection and execute MySql specific functions to my heart's content. You should never need to call GenericConnection.getConnection()! What you want to do is always call DataSource.getConnection(), as stated above. Thanks is advance, David Hope this helps, --- Matthias
Re: Struts questions for evaluation
Hello Struts users, We are currently evaluating Struts and other web (MVC) frameworks and would like to ask you some questions: - Is there some struts-config XML-generation from some modeling tool (Rose for instance) ? We would like to design a state or activity diagram in such a tool then generate the navigation XML file. - Can struts behave like a real state machine ? i.e. how to ensure that some Action is performed only if another Action (or view but is not ideal) has been performed with some result (success to be simple). We would like this to be Struts-controlled, not developper- controlled (check session variables, etc.). We found the built-in Struts token system but this seem only to be used to demarcate transactions in a set of views. This allow to demarcate a transaction end (token value change) but not an inconstency within the transaction (i.e. i valide twice the first page of the transaction) as the token value will not change. I hit the same weakness of struts a few months ago and I enhanced some struts classes in order to be able for each action to specify which action has to precede this action. This allows you to implement some kind of control flow. For instance you can now define an action that displays a logon page (displayLogon) and specify in the next action (logonAction, which gets executed when the user presses the submit button of the logon page) that displayLogon needed to be executed directly before. This is more powerful than the token mechanism. What I also did at the same time is an enhanced user authentication checking for each action. You can now specify a different user authorization class for each action, so you can easily implement a very fine grained user authorization. Exceptions (either control flow or user authentication exceptions) are handled by the framework and cause a forward to different error pages. I plan to propose this enhancement to the struts developer's group after release 1.0 is out. If you are interested in the meantime I can send you the code. - Why does the struts-example perform some scoped- variables cleanup at the end of every Action ? As these variables are defined as scoped in the struts- config XML file, they should naturally live during the specified scope lifetime. We don't understand that in the struts-example (maybe this is not mandatory). My understanding is: For request scope you normally do not need to clean up, because the object gets removed automatically, when the request is served. For the session scope you pretty often want to remove e. g. a form bean, when it is no longer needed to keep your session data lean. Thank you very much for your informations about Struts. Laurent. --- Matthias S/MIME Cryptographic Signature
What is procedure for deploy strut's example on iplanet
Hi all, I have installed iplanet webserver(IWS) 4.1 sp7. I am planning to work on IWS. Please any one tell me what i need to do for deploy my strut's examples ? I wish to get the following directory Structure. /Netscape /Server4 /https-4qzb11s Please let me know which directory, i need to put strut's jsp ? Which directory, i need to put .tld files ? Which directory, i need to create a directory callled org.apache.struts.example ? Please clarify me to work on strut to gear-up to next stage !! Please any one help me, i will be greatfull to you. Regards - Thilip __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Does anyne please have an example of using a multibox?
I have an iteration with each row displaying a checkbox, being set to the underlying bean property in the iteration. Each checkbox needs to have a different name, and this is not happening...they all have the same name, i need some way of individually referencing the checkboxes..please help!!!
RE: Suggestion/Idea for iterate tag: Iterate ResultSets
Well, I guess a way to work around that problem would be to create a data structure to represent the entire resultset. This could be a LinkedList of hashtables, with each key being the column name, and the value being the result. The disadvantage of this approach is that is requires the entire resultset to be loaded into memory, which may have some performance problems, right? --min -Original Message- From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 06, 2001 11:47 PM To: [EMAIL PROTECTED] Subject: Re: Suggestion/Idea for iterate tag: Iterate ResultSets Result sets ARE tied to the connection in a way. Some DB drivers throw exceptions when you try to manipulate data while you still have a pointer to rows. At work we were trying to manipulate a stream which was pointing to an output parameter in a stored proc while the connection was open. The result was that we had to convert the stream into another object (String in our case) and close the connection just to manipulate the data. - Original Message - From: Mindaugas Idzelis [EMAIL PROTECTED] To: struts [EMAIL PROTECTED] Sent: Sunday, May 06, 2001 9:33 PM Subject: Suggestion/Idea for iterate tag: Iterate ResultSets I just thought up of an excellent idea (although, I wasn't the only one). Use the iterate tag to iterate over the rows of a resultset. The column meta data could be exposed as beans named as the column name. A bean:write operation would display the data in the column. I did a search about this topic in the mailing list archive, and I found this message: http://marc.theaimsgroup.com/?l=struts-userm=98269295229785w=2 It talk about ResultSets being tied to connections. This is not the case. ResultSets are tied to the statements that produced them, and as far as I can tell, statements are not closed when the connection is closed. Other than that, It should be easy to change the iterate tag to support resultsets. If anyone is interested in helping me extend or develop a tag for this purpose, please message me. --min
JBoss and struts
Does JBoss work with Struts? Thanks Harden
JBoss and struts
Does JBoss work with Struts? Thanks Harden
Re: Struts questions for evaluation
I am interested in the code. Please send. Hello Struts users, We are currently evaluating Struts and other web (MVC) frameworks and would like to ask you some questions: - Is there some struts-config XML-generation from some modeling tool (Rose for instance) ? We would like to design a state or activity diagram in such a tool then generate the navigation XML file. - Can struts behave like a real state machine ? i.e. how to ensure that some Action is performed only if another Action (or view but is not ideal) has been performed with some result (success to be simple). We would like this to be Struts-controlled, not developper- controlled (check session variables, etc.). We found the built-in Struts token system but this seem only to be used to demarcate transactions in a set of views. This allow to demarcate a transaction end (token value change) but not an inconstency within the transaction (i.e. i valide twice the first page of the transaction) as the token value will not change. I hit the same weakness of struts a few months ago and I enhanced some struts classes in order to be able for each action to specify which action has to precede this action. This allows you to implement some kind of control flow. For instance you can now define an action that displays a logon page (displayLogon) and specify in the next action (logonAction, which gets executed when the user presses the submit button of the logon page) that displayLogon needed to be executed directly before. This is more powerful than the token mechanism. What I also did at the same time is an enhanced user authentication checking for each action. You can now specify a different user authorization class for each action, so you can easily implement a very fine grained user authorization. Exceptions (either control flow or user authentication exceptions) are handled by the framework and cause a forward to different error pages. I plan to propose this enhancement to the struts developer's group after release 1.0 is out. If you are interested in the meantime I can send you the code. - Why does the struts-example perform some scoped- variables cleanup at the end of every Action ? As these variables are defined as scoped in the struts- config XML file, they should naturally live during the specified scope lifetime. We don't understand that in the struts-example (maybe this is not mandatory). My understanding is: For request scope you normally do not need to clean up, because the object gets removed automatically, when the request is served. For the session scope you pretty often want to remove e. g. a form bean, when it is no longer needed to keep your session data lean. Thank you very much for your informations about Struts. Laurent. --- Matthias - Original Message - From: Matthias Bauer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 4:05 AM Subject: Re: JDBC driver specific functionality/GenericConnections Hello, I would like to access functionality specific to the MM MySql driver in an application that uses Struts' datasource pool and am having a bit of troubling casting a GenericConnection back to an org.gjt.mm.mysql.Connection. Casting from a GenericConnection to an org.gjt.mm.mysql.Connection results in a class cast exception; casting a Statement or PreparedStatement generated by the GenericConnection produces a null pointer exception. I am working with Struts 1.0-beta-1 and MM Mysql 2.0.4. If it sheds any light on the problem, the MM function I would like to access is PreparedStatement.getLastInsertID(). Has anyone successfully prosecuted this? You must not cast GenericConnection to What you really want to do is call DataSource.getConnection which returns a Connection object like so: DataSource ds = getServlet().findDataSource(null); Connection con = ds.getConnection(); You can cast this connection to org.gjt.mm.mysql.Connection without any problems! On a tangential note--why is the getConnection() method in GenericConnection private? Were it public, I assume I could use it to get an MM Connection and execute MySql specific functions to my heart's content. You should never need to call GenericConnection.getConnection()! What you want to do is always call DataSource.getConnection(), as stated above. Thanks is advance, David Hope this helps, --- Matthias
ActionServlet to change language ?
Hi all,
I want to use a simple action to change the language in a site,
but I would like this feature to be available on all pages of the site.
I'm using a template, and the same menu (with language selection)
is included in each page.
My question is : When a visitor decide to change the language,
how could I know the URL where he was and where I had to come
back ?
In other words, how can I complete the following code ?
+
public final class ChangeLang extends Action {
public ActionForward perform(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
// Extract parameters we will need
String requested = (String)request.getParameter( lang );
if( requested == null )
return (mapping.findForward(error));
if( requested.equalsIgnoreCase( FR ) )
setLocale( request, Locale.FRANCE );
if( requested.equalsIgnoreCase( UK ) )
setLocale( request, Locale.UK );
if( requested.equalsIgnoreCase( DE ) )
setLocale( request, Locale.GERMAN );
return ( ? );
}
protected void setLocale( HttpServletRequest request, Locale locale
)
{
HttpSession session = request.getSession(false);
if (session != null)
session.setAttribute(Action.LOCALE_KEY, locale);
}
}
+
In my strus-config.xml :
+
action-mappings
action path=/ChLang actionClass=classes.ChangeLang
forward name=error path=/error.jsp/
/action
/action-mappings
+
My menu :
+
%@ taglib uri='/WEB-INF/struts-html.tld' prefix='html' %
table width=100%
tr
td
Select Language :
html:link page=/ChLang.do?lang=FRFR/html:link |
html:link page=/ChLang.do?lang=ENEN/html:link |
html:link page=/ChLang.do?lang=NLNL/html:link |
html:link page=/ChLang.do?lang=DD/html:link
/td
/tr
/table
+
Thanks.
--
Olivier DUCHÊNE
RE: Struts questions for evaluation
me too -Original Message- From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:21 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Struts questions for evaluation I am interested in the code. Please send. Hello Struts users, We are currently evaluating Struts and other web (MVC) frameworks and would like to ask you some questions: - Is there some struts-config XML-generation from some modeling tool (Rose for instance) ? We would like to design a state or activity diagram in such a tool then generate the navigation XML file. - Can struts behave like a real state machine ? i.e. how to ensure that some Action is performed only if another Action (or view but is not ideal) has been performed with some result (success to be simple). We would like this to be Struts-controlled, not developper- controlled (check session variables, etc.). We found the built-in Struts token system but this seem only to be used to demarcate transactions in a set of views. This allow to demarcate a transaction end (token value change) but not an inconstency within the transaction (i.e. i valide twice the first page of the transaction) as the token value will not change. I hit the same weakness of struts a few months ago and I enhanced some struts classes in order to be able for each action to specify which action has to precede this action. This allows you to implement some kind of control flow. For instance you can now define an action that displays a logon page (displayLogon) and specify in the next action (logonAction, which gets executed when the user presses the submit button of the logon page) that displayLogon needed to be executed directly before. This is more powerful than the token mechanism. What I also did at the same time is an enhanced user authentication checking for each action. You can now specify a different user authorization class for each action, so you can easily implement a very fine grained user authorization. Exceptions (either control flow or user authentication exceptions) are handled by the framework and cause a forward to different error pages. I plan to propose this enhancement to the struts developer's group after release 1.0 is out. If you are interested in the meantime I can send you the code. - Why does the struts-example perform some scoped- variables cleanup at the end of every Action ? As these variables are defined as scoped in the struts- config XML file, they should naturally live during the specified scope lifetime. We don't understand that in the struts-example (maybe this is not mandatory). My understanding is: For request scope you normally do not need to clean up, because the object gets removed automatically, when the request is served. For the session scope you pretty often want to remove e. g. a form bean, when it is no longer needed to keep your session data lean. Thank you very much for your informations about Struts. Laurent. --- Matthias - Original Message - From: Matthias Bauer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 4:05 AM Subject: Re: JDBC driver specific functionality/GenericConnections Hello, I would like to access functionality specific to the MM MySql driver in an application that uses Struts' datasource pool and am having a bit of troubling casting a GenericConnection back to an org.gjt.mm.mysql.Connection. Casting from a GenericConnection to an org.gjt.mm.mysql.Connection results in a class cast exception; casting a Statement or PreparedStatement generated by the GenericConnection produces a null pointer exception. I am working with Struts 1.0-beta-1 and MM Mysql 2.0.4. If it sheds any light on the problem, the MM function I would like to access is PreparedStatement.getLastInsertID(). Has anyone successfully prosecuted this? You must not cast GenericConnection to What you really want to do is call DataSource.getConnection which returns a Connection object like so: DataSource ds = getServlet().findDataSource(null); Connection con = ds.getConnection(); You can cast this connection to org.gjt.mm.mysql.Connection without any problems! On a tangential note--why is the getConnection() method in GenericConnection private? Were it public, I assume I could use it to get an MM Connection and execute MySql specific functions to my heart's content. You should never need to call GenericConnection.getConnection()! What you want to do is always call DataSource.getConnection(), as stated above. Thanks is advance, David Hope this helps, --- Matthias
FYI: asocial behaviour of j2eesdk1.3 ( deploytool )
I solved my problem with form tag.
I discovered that action mappings in form
!-- Standard Action Servlet Mapping --
servlet-mapping
servlet-nameaction/servlet-name
url-pattern*.do/url-pattern
/servlet-mapping
are unsuitable for use with j2sdkee1.3. Deploytool
( or whatever else ) botches web.xml and changes
*.do
to /*.do. Unfortunately, struts form tag does
following:
--- snip ---
if (servletMapping != null) {
String actionMapping =
getActionMappingName();
if (servletMapping.startsWith(*.)) {
value.append(actionMapping);
value.append(servletMapping.substring(1));
} else if (servletMapping.endsWith(/*))
{
value.append(servletMapping.substring
(0,
servletMapping.length() - 2));
value.append(actionMapping);
}
}
-- snap---
This way action mapping wil be never found,
and you will go on the walls.
Workable solution would be either to patch form
tag, or use mappings in form:
!-- Standard Action Servlet Mapping --
servlet-mapping
servlet-nameaction/servlet-name
url-pattern/do/*/url-pattern
/servlet-mapping
This worked for me fine...
thanks for your attention...
regards,
=
Konstantin Priblouda ( ko5tik )Freelance Software developer
http://www.pribluda.de play java games - http://www.yook.de
render charts online - http://www.pribluda.de/povray/
__
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
RE: Suggestion/Idea for iterate tag: Iterate ResultSets
I just thought of another option: If resultsets are tied to a connection and a statement, then specify the sql query within the iterator: Hypothetical taglibs: sql:query id=myQuery SELECT col1, col2 FROM table WHERE id 1 !-- even use bean:write in here to dynamically make queries -- /sql:query logic:iterate id=row query=myQuery bean:write name=row property=col1/ bean:write name=row property=col2/ br /logic:iterate Where sql:query would only be evauluated once per iteration. Would this be possible to create? I have never authored a taglib, so any feedback from taglib veterans is greatly appreciated. I think this would be a great addition to the taglibs framework. --min -Original Message- From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 06, 2001 11:47 PM To: [EMAIL PROTECTED] Subject: Re: Suggestion/Idea for iterate tag: Iterate ResultSets Result sets ARE tied to the connection in a way. Some DB drivers throw exceptions when you try to manipulate data while you still have a pointer to rows. At work we were trying to manipulate a stream which was pointing to an output parameter in a stored proc while the connection was open. The result was that we had to convert the stream into another object (String in our case) and close the connection just to manipulate the data. - Original Message - From: Mindaugas Idzelis [EMAIL PROTECTED] To: struts [EMAIL PROTECTED] Sent: Sunday, May 06, 2001 9:33 PM Subject: Suggestion/Idea for iterate tag: Iterate ResultSets I just thought up of an excellent idea (although, I wasn't the only one). Use the iterate tag to iterate over the rows of a resultset. The column meta data could be exposed as beans named as the column name. A bean:write operation would display the data in the column. I did a search about this topic in the mailing list archive, and I found this message: http://marc.theaimsgroup.com/?l=struts-userm=98269295229785w=2 It talk about ResultSets being tied to connections. This is not the case. ResultSets are tied to the statements that produced them, and as far as I can tell, statements are not closed when the connection is closed. Other than that, It should be easy to change the iterate tag to support resultsets. If anyone is interested in helping me extend or develop a tag for this purpose, please message me. --min
RE: Suggestion/Idea for iterate tag: Iterate ResultSets
If you are interested in executing SQL from your JSPs, the taglibs project might save you some time. Check into: http://jakarta.apache.org/taglibs/doc/dbtags-doc/intro.html For what its worth, this approach breaks the model-view separation struts may have provided for your project. If that's ok for your project, then the afore-mentioned taglibs should save you time. On the other hand, if your not sure what model-view separation is, I would recommend reviewing the Struts User's Guide - Introduction at: http://jakarta.apache.org/struts/userGuide/introduction.html Regards, Levi Cook -Original Message- From: Mindaugas Idzelis [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 9:06 AM To: [EMAIL PROTECTED]; Jonathan Asbell Subject: RE: Suggestion/Idea for iterate tag: Iterate ResultSets I just thought of another option: If resultsets are tied to a connection and a statement, then specify the sql query within the iterator: Hypothetical taglibs: sql:query id=myQuery SELECT col1, col2 FROM table WHERE id 1 !-- even use bean:write in here to dynamically make queries -- /sql:query logic:iterate id=row query=myQuery bean:write name=row property=col1/ bean:write name=row property=col2/ br /logic:iterate Where sql:query would only be evauluated once per iteration. Would this be possible to create? I have never authored a taglib, so any feedback from taglib veterans is greatly appreciated. I think this would be a great addition to the taglibs framework. --min -Original Message- From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 06, 2001 11:47 PM To: [EMAIL PROTECTED] Subject: Re: Suggestion/Idea for iterate tag: Iterate ResultSets Result sets ARE tied to the connection in a way. Some DB drivers throw exceptions when you try to manipulate data while you still have a pointer to rows. At work we were trying to manipulate a stream which was pointing to an output parameter in a stored proc while the connection was open. The result was that we had to convert the stream into another object (String in our case) and close the connection just to manipulate the data. - Original Message - From: Mindaugas Idzelis [EMAIL PROTECTED] To: struts [EMAIL PROTECTED] Sent: Sunday, May 06, 2001 9:33 PM Subject: Suggestion/Idea for iterate tag: Iterate ResultSets I just thought up of an excellent idea (although, I wasn't the only one). Use the iterate tag to iterate over the rows of a resultset. The column meta data could be exposed as beans named as the column name. A bean:write operation would display the data in the column. I did a search about this topic in the mailing list archive, and I found this message: http://marc.theaimsgroup.com/?l=struts-userm=98269295229785w=2 It talk about ResultSets being tied to connections. This is not the case. ResultSets are tied to the statements that produced them, and as far as I can tell, statements are not closed when the connection is closed. Other than that, It should be easy to change the iterate tag to support resultsets. If anyone is interested in helping me extend or develop a tag for this purpose, please message me. --min
RE: Suggestion/Idea for iterate tag: Iterate ResultSets
I think Struts does a good job dealing with the whole MVC separation issues... Embedding SQL into yet-another-custom tag seems to (IMHO) violate a number of the principles Struts is trying to uphold. Truth-be-told, I haven't been a real JSP/custom tag fan from the start (aren't there enough languages to learn alrady? *:^) after spending countless hours sifting through bugs in other folkk's ASP pages and ColdFusion pages, but the whole Struts framework feels right and does a great job letting you have a *manageable*, *flexible* and *structured* view while doing most of the controller work for you, leaving only the icky model details to really work out. The fact that it works with Java is icing on the cake *:^) Tossing SQL directly into the view re-introduces the potential for unmanageabe web code (again, IMHO). It would be great to hear from those who have dealt with this more in the Java world, tho, on their feelings of SQL-JSP-MVC. As an aside, there is a good start on SQL taglibs - the DBTags tag library - in the jakarta-taglibs project - http://jakarta.apache.org/taglibs/doc/dbtags-doc/intro.html in case an individual wanted to see how to integrate this into Struts w/o re-inventing the wheel. An excerpt from their example page yields the following (which looks similar to what you were trying to do): %-- print the rows in an HTML table --% table sql:statement id=stmt1 conn=conn1 sql:query select id, name, description from test_books order by 1 /sql:query %-- loop through the rows of your query --% sql:resultSet id=rset2 tr tdsql:getColumn position=1//td tdsql:getColumn position=2//td tdsql:getColumn position=3/ %-- print out a comment if the book has no description --% sql:wasNull[no description]/sql:wasNull/td /tr /sql:resultSet /sql:statement /table boB Rudis [EMAIL PROTECTED] http://www.rudis.net/ ++ | Mind the gap | ++ On Mon, 7 May 2001, Mindaugas Idzelis wrote: I just thought of another option: If resultsets are tied to a connection and a statement, then specify the sql query within the iterator: Hypothetical taglibs: sql:query id=myQuery SELECT col1, col2 FROM table WHERE id 1 !-- even use bean:write in here to dynamically make queries -- /sql:query logic:iterate id=row query=myQuery bean:write name=row property=col1/ bean:write name=row property=col2/ br /logic:iterate Where sql:query would only be evauluated once per iteration. Would this be possible to create? I have never authored a taglib, so any feedback from taglib veterans is greatly appreciated. I think this would be a great addition to the taglibs framework. --min -Original Message- From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 06, 2001 11:47 PM To: [EMAIL PROTECTED] Subject: Re: Suggestion/Idea for iterate tag: Iterate ResultSets Result sets ARE tied to the connection in a way. Some DB drivers throw exceptions when you try to manipulate data while you still have a pointer to rows. At work we were trying to manipulate a stream which was pointing to an output parameter in a stored proc while the connection was open. The result was that we had to convert the stream into another object (String in our case) and close the connection just to manipulate the data. - Original Message - From: Mindaugas Idzelis [EMAIL PROTECTED] To: struts [EMAIL PROTECTED] Sent: Sunday, May 06, 2001 9:33 PM Subject: Suggestion/Idea for iterate tag: Iterate ResultSets I just thought up of an excellent idea (although, I wasn't the only one). Use the iterate tag to iterate over the rows of a resultset. The column meta data could be exposed as beans named as the column name. A bean:write operation would display the data in the column. I did a search about this topic in the mailing list archive, and I found this message: http://marc.theaimsgroup.com/?l=struts-userm=98269295229785w=2 It talk about ResultSets being tied to connections. This is not the case. ResultSets are tied to the statements that produced them, and as far as I can tell, statements are not closed when the connection is closed. Other than that, It should be easy to change the iterate tag to support resultsets. If anyone is interested in helping me extend or develop a tag for this purpose, please message me. --min
RE: Suggestion/Idea for iterate tag: Iterate ResultSets
I haven't used it, but this looks similar to whats been developed in the jakarta taglibs project - see JDBC taglib. http://jakarta.apache.org/taglibs/doc/jdbc-doc/intro.html Niall -Original Message- From: Mindaugas Idzelis [mailto:[EMAIL PROTECTED]] Sent: 07 May 2001 15:06 To: [EMAIL PROTECTED]; Jonathan Asbell Subject: RE: Suggestion/Idea for iterate tag: Iterate ResultSets I just thought of another option: If resultsets are tied to a connection and a statement, then specify the sql query within the iterator: Hypothetical taglibs: sql:query id=myQuery SELECT col1, col2 FROM table WHERE id 1 !-- even use bean:write in here to dynamically make queries -- /sql:query logic:iterate id=row query=myQuery bean:write name=row property=col1/ bean:write name=row property=col2/ br /logic:iterate Where sql:query would only be evauluated once per iteration. Would this be possible to create? I have never authored a taglib, so any feedback from taglib veterans is greatly appreciated. I think this would be a great addition to the taglibs framework. --min -Original Message- From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 06, 2001 11:47 PM To: [EMAIL PROTECTED] Subject: Re: Suggestion/Idea for iterate tag: Iterate ResultSets Result sets ARE tied to the connection in a way. Some DB drivers throw exceptions when you try to manipulate data while you still have a pointer to rows. At work we were trying to manipulate a stream which was pointing to an output parameter in a stored proc while the connection was open. The result was that we had to convert the stream into another object (String in our case) and close the connection just to manipulate the data. - Original Message - From: Mindaugas Idzelis [EMAIL PROTECTED] To: struts [EMAIL PROTECTED] Sent: Sunday, May 06, 2001 9:33 PM Subject: Suggestion/Idea for iterate tag: Iterate ResultSets I just thought up of an excellent idea (although, I wasn't the only one). Use the iterate tag to iterate over the rows of a resultset. The column meta data could be exposed as beans named as the column name. A bean:write operation would display the data in the column. I did a search about this topic in the mailing list archive, and I found this message: http://marc.theaimsgroup.com/?l=struts-userm=98269295229785w=2 It talk about ResultSets being tied to connections. This is not the case. ResultSets are tied to the statements that produced them, and as far as I can tell, statements are not closed when the connection is closed. Other than that, It should be easy to change the iterate tag to support resultsets. If anyone is interested in helping me extend or develop a tag for this purpose, please message me. --min
RE: FW: Session scope
I have a few of questions: 1. Did WL do the JDBC session persistence automatically (i.e. through configuration)? 2. How does 'app server load balancing' affect performance? I'm of the impression that having a load-balancing mechanism redirecting requests based on sessionId/etc would not affect performance too much, but it's just my theory. If I have 2 JVM's, and my load-balancing mechanism has to redirect requests to the 'appropriate' box instead of the least-loaded box, then I've given-up some performance, by definition, haven't I? Is there a legitimate possibility that one of my JVM's could get stuck with the majority of overactive users and slam the box? To me, it only seems this would happen if my load-balancing mechanism was a piece 'o junk. 3. One of the primary reasons I'm trying to sync my JVM sessions with that of the Oracle 8i database is because much/all of our website is written in PL/SQL using Oracle App Server. We maintain (Oracle db) package-level state. I need logged-in users to be able to move seemlessly from my app, written in Java, to the PL/SQL world. What is the best way (is there a way?) to sync-up my Java app with PL/SQL apps? My initial approach will be to override some part of ActionServlet (haven't read details yet) and have all requests hit the db (ouch) before an 'action' is performed. In my case, session-level failover would actually be a benefit that I'm not specifically targeting. I thought only NASA did that stuff anyway. --Peter-- --- Calvin Yu [EMAIL PROTECTED] wrote: Here's my experience with this issue. We used in-memory session failover in WL, but due to problems with the WL proxy we switched to JDBC session persistence. We then dropped clustering and session persistence altogether because of performance reasons and used switches to make sure that users always hit the same WL instance. Things to note about my experience: * There were ways to optimize the session database (Oracle) which we didn't explore. * Session failover wasn't as important as we thought. At least not more so than performance. Calvin --- Chen, Yong [EMAIL PROTECTED] wrote: Application server level load balancing is the answer to the problem. I don't see there is a strong reason to synchronize two sessions on two different app servers. Because the web server or proxy server will establish the link between the client and app server the very first time the connection is made. After that, the client (browser) will bind to the same app server. So, session info should only be kept in that particular app server. However, if you want to do session level fail-over, then like Weblogic app server, you will utilize their cluster feature to sync the secondary app server with the primary app server in case the primary is down. This requires to use BEA's weblogic proxy feature to detect such failure of primary app server down. In current generation of web apps, should any services is needed to be distributed, you can use EJB, RMI, CORBA or COM/COM+. Session related info should be in the memory of app server. Session is transient, not persistent. Yong Chen -Original Message- From: Peter Smith [mailto:[EMAIL PROTECTED]] Sent: Monday, April 23, 2001 5:38 PM To: [EMAIL PROTECTED] Subject: Re: FW: Session scope I'm definitely considering running Struts with at least 2 JVMs - one on each of 2 boxes. At first I didn't even consider the effects of running multiple JVMs - never done it! Currently, my company has a big Oracle focus. There's only one Oracle instance so they're using it to maintain session info across multiple app servers. This requires a db hit for every HTTP request. I can handle the memory requirements. I just want a better way to coordinte session info across JVM's. In the past I've written a poor-man's 'serialization' module for PERL which just kicked-out all the accumulated HTML parameters into HIDDEN... tags. Wonder if I can do something similar for Struts environment w/o giving up too much of the functionality I'm using Struts for in the first place. Are there any gotchas we can think of with using Struts across JVM's? P.S. I wonder if Tomcat project is planning some kind of session-sync technology. --- Maguire, James [EMAIL PROTECTED] wrote: Obviously, design decisions have been made on the session context. Is anyone running (or considering running) Struts in a truly distributed server infrastructure? Does Craig's suggestion of Serializable session beans stand up under volume? Just looking for some pointers. Jim -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Friday, April 13, 2001 11:03 PM To: Struts-User@Jakarta. Apache. Org (E-mail) Subject: Re: Session scope On
RE: Struts questions for evaluation
I am interested too From: "Nanduri, Amarnath" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Subject: RE: Struts questions for evaluation Date: Mon, 7 May 2001 08:20:00 -0400 me too -Original Message- From: Jonathan Asbell [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:21 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Struts questions for evaluation I am interested in the code. Please send. Hello Struts users, We are currently evaluating Struts and other web (MVC) frameworks and would like to ask you some questions: - Is there some struts-config XML-generation from some modeling tool (Rose for instance) ? We would like to design a state or activity diagram in such a tool then generate the navigation XML file. - Can struts behave like a real state machine ? i.e. how to ensure that some Action is performed only if another Action (or view but is not ideal) has been performed with some result (success to be simple). We would like this to be Struts-controlled, not developper- controlled (check session variables, etc.). We found the built-in Struts token system but this seem only to be used to demarcate transactions in a set of views. This allow to demarcate a transaction end (token value change) but not an inconstency within the transaction (i.e. i valide twice the first page of the transaction) as the token value will not change. I hit the same weakness of struts a few months ago and I enhanced some struts classes in order to be able for each action to specify which action has to precede this action. This allows you to implement some kind of control flow. For instance you can now define an action that displays a logon page (displayLogon) and specify in the next action (logonAction, which gets executed when the user presses the submit button of the logon page) that displayLogon needed to be executed directly before. This is more powerful than the token mechanism. What I also did at the same time is an enhanced user authentication checking for each action. You can now specify a different user authorization class for each action, so you can easily implement a very fine grained user authorization. Exceptions (either control flow or user authentication exceptions) are handled by the framework and cause a forward to different error pages. I plan to propose this enhancement to the struts developer's group after release 1.0 is out. If you are interested in the meantime I can send you the code. - Why does the struts-example perform some scoped- variables cleanup at the end of every Action ? As these variables are defined as scoped in the struts- config XML file, they should naturally live during the specified scope lifetime. We don't understand that in the struts-example (maybe this is not mandatory). My understanding is: For request scope you normally do not need to clean up, because the object gets removed automatically, when the request is served. For the session scope you pretty often want to remove e. g. a form bean, when it is no longer needed to keep your session data lean. Thank you very much for your informations about Struts. Laurent. --- Matthias - Original Message - From: "Matthias Bauer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, May 07, 2001 4:05 AM Subject: Re: JDBC driver specific functionality/GenericConnections Hello, I would like to access functionality specific to the MM MySql driver in an application that uses Struts' datasource pool and am having a bit of troubling casting a GenericConnection back to an org.gjt.mm.mysql.Connection. Casting from a GenericConnection to an org.gjt.mm.mysql.Connection results in a class cast exception; casting a Statement or PreparedStatement generated by the GenericConnection produces a null pointer exception. I am working with Struts 1.0-beta-1 and MM Mysql 2.0.4. If it sheds any light on the problem, the MM function I would like to access is PreparedStatement.getLastInsertID(). Has anyone successfully prosecuted this? You must not cast GenericConnection to What you really want to do is call DataSource.getConnection which returns a Connection object like so: DataSource ds = getServlet().findDataSource(null); Connection con = ds.getConnection(); You can cast this connection to org.gjt.mm.mysql.Connection without any problems! On a tangential note--why is the getConnection() method in GenericConnection private? Were it public, I assume I could use it to get an MM Connection and execute MySql specific functions to my heart's content. You should never need to call GenericConnection.getConnection()! What you want to do is always call DataSource.getConnection(), as stated above.
Potential Security Flaw in Struts MVC
I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User (the model representing the user) UserForm (an enrollment form for a new user) UserAction (Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the "Administrative User Flag" option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an "Administrative User Flag" field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the "Administrative Flag" on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
still not getting struts to work yet with Tomcat 3.2.1
Hello,
I've been trying for awhile to get my own version of the 'logon' example
to work. I've done everything essentially the exact same as the struts
example, except using 'login' where I saw 'logon'.
Upon starting up Tomcat, there is a bunch of output generated. After
reading this output, it seems that my action classes and action mappings
are not getting set up in the servlet context, since I do not see any
output - though I do see all the struts example servlet contexts getting
setup. For example: 'ActionServlet.addMapping(...)'.
I think the problem might be related to resolving the DTD entity in my
struts-config.xml file. Here is a snippet for the output I receive
after staring Tomcat. Has anyone seen this problem at all. I would
appreciate any help.
Thanks,
Brett Procek
Starting tomcat. Check logs/tomcat.log for error messages
...
resolveEntity('-//Apache Software Foundation//DTD Struts Configuration
1.0//EN',
'jar:file:/export/home/tomcat/webapps/TestApp/WEB-INF/lib/struts.jar!/or
g/apache/struts/resources/struts-config_1_0.dtd')
Not registered, use system identifier
...
problem with weblogic 5.1sp9 and example webapp
I am new to struts, and am trying to access the example webapp. I am using Weblogic 5.1 with service pack 9 installed, and have added xerces.jar to the JAVA_CLASSPATH, and the examples/WEB-INF/classes, examples/WEB-INF/lib/struts.jar listings to the WEBLOGIC_CLASSPATH (I expanded the sample from the war file)... When I try to access the webapp, I get the following stacktrace: java.lang.NoSuchMethodError at weblogic.servlet.jsp.MyAttInfo.init(StandardTagLib.java:34) at weblogic.servlet.jsp.StandardTagLib.processTag(StandardTagLib.java:280) at weblogic.servlet.jsp.StandardTagLib.processTagElements(StandardTagLib.ja va:146) at weblogic.servlet.jsp.StandardTagLib.init(StandardTagLib.java:125) at weblogic.servlet.jsp.JspLexer.loadTagLib(JspLexer.java:95) at weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE_BODY(JspLexer.java:3873) at weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE(JspLexer.java:3623) at weblogic.servlet.jsp.JspLexer.mDIRECTIVE(JspLexer.java:3484) at weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:1817) at weblogic.servlet.jsp.JspLexer.mTOKEN(JspLexer.java:1658) at weblogic.servlet.jsp.JspLexer.nextToken(JspLexer.java:1548) at weblogic.servlet.jsp.JspLexer.parse(JspLexer.java:888) at weblogic.servlet.jsp.JspParser.doit(JspParser.java:69) at weblogic.servlet.jsp.JspParser.parse(JspParser.java:125) at weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:109) at weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java:242) at weblogic.servlet.jsp.JspStub.compilePage(JspStub.java:312) at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:227) at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.jav a:200) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl. java:115) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl. java:138) at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContex tImpl.java:915) at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContex tImpl.java:879) at weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletCon textManager.java:269) at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:3 65) at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:253) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129) Does anyone have any ideas about how to solve this?? Any help would be greatly appreciated. John Casey
Problems with Struts example in Netscape 4.75
Hi! I'm just wondering if anybody else encountered problems with Netscape and the Struts example. The POST method (Register for the MailReader Demonstration Application) seems to take forever until it gives back a response (however clicking on the browser's title-bar immediately solves this problem). I'm not sure if this is a struts problem because I found some related bugs in the tomcat bug-database (which has been fixed in tomcat 3.2). I had problems reproducing it with a simple servlet (non using struts). My Environment: - Tomcat 3.2.1 - Struts 1.0 beta - Netscape 4.75 en Thanks in advance, Tobias
RE: Potential Security Flaw in Struts MVC
Jeff, Are you asking if book marking a URL that contains query parameters might be a security risk? Anthony -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:37 AM To: [EMAIL PROTECTED] Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User(the model representing the user) UserForm(an enrollment form for a new user) UserAction(Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the Administrative User Flag option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an Administrative User Flag field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the Administrative Flag on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
RE: Potential Security Flaw in Struts MVC
However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an Administrative User Flag field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the Administrative Flag on the user. Unless, of course, the developer makes special provisions to prevent this behavior. Creating a secure web application means that *every* HTTP request should be checked for validity. Any data that comes from the client is suspect. This is no more or less true with Struts than without it. -- Curt Hagenlocher [EMAIL PROTECTED]
Re: still not getting struts to work yet with Tomcat 3.2.1
I think the problem might be related to resolving the DTD entity in my struts-config.xml file. Here is a snippet for the output I receive after staring Tomcat. Has anyone seen this problem at all. I would appreciate any help. Following installation instructions worked for me. If you like you can grab my war at: http://www.pribluda.de/webesa.war Which is just a small example with working login ( very dumb one ) It could also help, if you post web.xml and struts-config.xml = Konstantin Priblouda ( ko5tik )Freelance Software developer http://www.pribluda.de play java games - http://www.yook.de render charts online - http://www.pribluda.de/povray/ __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: Potential Security Flaw in Struts MVC
That is not what my thinking was. But that could be an issue also. My concern is someone intentionally and maliciously creating a form to supply more parameters than originally intented by the developer. For instance, consider the UserForm fields: Name(available to enrollment administrative interface) Address(available to enrollment administrative interface) Phone(available to enrollment administrative interface) Email(available to enrollment administrative interface) ApprovedUserFlag(available to administrative interface only) AdministrativeUserFlag (available to administrative interface only) If a user knows your naming concention, they can write their own form to override the administrative-level fields above. - Original Message - From: Anthony Martin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 11:59 AM Subject: RE: Potential Security Flaw in Struts MVC Jeff, Are you asking if book marking a URL that contains query parameters might be a security risk? Anthony -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:37 AM To: [EMAIL PROTECTED] Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User(the model representing the user) UserForm(an enrollment form for a new user) UserAction(Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the Administrative User Flag option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an Administrative User Flag field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the Administrative Flag on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
Re: Potential Security Flaw in Struts MVC
Curt, I don't dispute what your saying. However, to the casual struts user this fact may be easily overlooked and exploited by a hacker. - jeff - Original Message - From: Curt Hagenlocher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 12:10 PM Subject: RE: Potential Security Flaw in Struts MVC However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an Administrative User Flag field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the Administrative Flag on the user. Unless, of course, the developer makes special provisions to prevent this behavior. Creating a secure web application means that *every* HTTP request should be checked for validity. Any data that comes from the client is suspect. This is no more or less true with Struts than without it. -- Curt Hagenlocher [EMAIL PROTECTED]
RE: ActionServlet to change language ?
Title: RE: ActionServlet to change language ?
One solution is for each page to have a hidden field that contains it's relative path. Then you can forard to that page after you have changed the locale.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 07, 2001 5:17 AM
To: [EMAIL PROTECTED]
Subject: ActionServlet to change language ?
Hi all,
I want to use a simple action to change the language in a site,
but I would like this feature to be available on all pages of the site.
I'm using a template, and the same menu (with language selection)
is included in each page.
My question is : When a visitor decide to change the language,
how could I know the URL where he was and where I had to come
back ?
In other words, how can I complete the following code ?
+
public final class ChangeLang extends Action {
public ActionForward perform(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
// Extract parameters we will need
String requested = (String)request.getParameter( lang );
if( requested == null )
return (mapping.findForward(error));
if( requested.equalsIgnoreCase( FR ) )
setLocale( request, Locale.FRANCE );
if( requested.equalsIgnoreCase( UK ) )
setLocale( request, Locale.UK );
if( requested.equalsIgnoreCase( DE ) )
setLocale( request, Locale.GERMAN );
return ( ? );
}
protected void setLocale( HttpServletRequest request, Locale locale
)
{
HttpSession session = request.getSession(false);
if (session != null)
session.setAttribute(Action.LOCALE_KEY, locale);
}
}
+
In my strus-config.xml :
+
action-mappings
action path=/ChLang actionClass=classes.ChangeLang
forward name=error path=/error.jsp/
/action
/action-mappings
+
My menu :
+
%@ taglib uri='/WEB-INF/struts-html.tld' prefix='html' %
table width=100%
tr
td
Select Language :
html:link page=/ChLang.do?lang=FRFR/html:link |
html:link page=/ChLang.do?lang=ENEN/html:link |
html:link page=/ChLang.do?lang=NLNL/html:link |
html:link page=/ChLang.do?lang=DD/html:link
/td
/tr
/table
+
Thanks.
--
Olivier DUCHÊNE
RE: Potential Security Flaw in Struts MVC
Wouldn't this not be a concern because the user would never be in the session on the target server? -Original Message-From: Jeff Trent [mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 11:37 AMTo: [EMAIL PROTECTED]Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User (the model representing the user) UserForm (an enrollment form for a new user) UserAction (Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the "Administrative User Flag" option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an "Administrative User Flag" field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the "Administrative Flag" on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
Re: Potential Security Flaw in Struts MVC
There is a security risk here as you describe, if (and only if) you are using a generic introspection-based function (like Struts' PropertyUtils.copyBean) to copy the values from the UserForm object to the User object. There are several ways to avoid this -- 1. Don't put an admin flag "setter" method in your User class. 2. In UserAction, don't use the generic bean copy utility -- instead, manually copy the values, excluding the admin flag. 3. As a smarter alternative to #2, don't use a generic bean copy utility -- instead, write an intelligent copy function in the User class, which "knows" that it's copying FROM a UserForm, TO a User, and therefore, skip the copying of the Admin flag. Bryan Jeff Trent wrote: 002501c0d70b$9df009a0$6401a8c0@PROVIDENCE"> I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User (the model representing the user) UserForm (an enrollment form for a new user) UserAction (Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the "Administrative User Flag" option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an "Administrative User Flag" field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the "Administrative Flag" on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
RE: problem with weblogic 5.1sp9 and example webapp
Title: RE: problem with weblogic 5.1sp9 and example webapp Use sp8, sp9 is really, really bad. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:58 AM To: [EMAIL PROTECTED] Subject: problem with weblogic 5.1sp9 and example webapp I am new to struts, and am trying to access the example webapp. I am using Weblogic 5.1 with service pack 9 installed, and have added xerces.jar to the JAVA_CLASSPATH, and the examples/WEB-INF/classes, examples/WEB-INF/lib/struts.jar listings to the WEBLOGIC_CLASSPATH (I expanded the sample from the war file)... When I try to access the webapp, I get the following stacktrace: java.lang.NoSuchMethodError at weblogic.servlet.jsp.MyAttInfo.init(StandardTagLib.java:34) at weblogic.servlet.jsp.StandardTagLib.processTag(StandardTagLib.java:280) at weblogic.servlet.jsp.StandardTagLib.processTagElements(StandardTagLib.ja va:146) at weblogic.servlet.jsp.StandardTagLib.init(StandardTagLib.java:125) at weblogic.servlet.jsp.JspLexer.loadTagLib(JspLexer.java:95) at weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE_BODY(JspLexer.java:3873) at weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE(JspLexer.java:3623) at weblogic.servlet.jsp.JspLexer.mDIRECTIVE(JspLexer.java:3484) at weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:1817) at weblogic.servlet.jsp.JspLexer.mTOKEN(JspLexer.java:1658) at weblogic.servlet.jsp.JspLexer.nextToken(JspLexer.java:1548) at weblogic.servlet.jsp.JspLexer.parse(JspLexer.java:888) at weblogic.servlet.jsp.JspParser.doit(JspParser.java:69) at weblogic.servlet.jsp.JspParser.parse(JspParser.java:125) at weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:109) at weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java:242) at weblogic.servlet.jsp.JspStub.compilePage(JspStub.java:312) at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:227) at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.jav a:200) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl. java:115) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl. java:138) at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContex tImpl.java:915) at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContex tImpl.java:879) at weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletCon textManager.java:269) at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:3 65) at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:253) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129) Does anyone have any ideas about how to solve this?? Any help would be greatly appreciated. John Casey
populating list of records
I have one jsp page with submit button, I want when user click on this button the action performed method will lookup all the information related to the user from the data base and display it on the 2nd page? what kind of bean and/or struts tag do I need to perform this task for the 2nd page to display the list or rows? it can be 0...n number of rows. any idea and help? Thank N Regards
RE: Potential Security Flaw in Struts MVC
Title: RE: Potential Security Flaw in Struts MVC You can easily guard against this by using simple JavaBeans in the presentation layer and having your action class do the persistant storage from you JavaBean view layer. -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 9:50 AM To: [EMAIL PROTECTED] Subject: Re: Potential Security Flaw in Struts MVC That is not what my thinking was. But that could be an issue also. My concern is someone intentionally and maliciously creating a form to supply more parameters than originally intented by the developer. For instance, consider the UserForm fields: Name (available to enrollment administrative interface) Address (available to enrollment administrative interface) Phone (available to enrollment administrative interface) Email (available to enrollment administrative interface) ApprovedUserFlag (available to administrative interface only) AdministrativeUserFlag (available to administrative interface only) If a user knows your naming concention, they can write their own form to override the administrative-level fields above. - Original Message - From: Anthony Martin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 11:59 AM Subject: RE: Potential Security Flaw in Struts MVC Jeff, Are you asking if book marking a URL that contains query parameters might be a security risk? Anthony -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:37 AM To: [EMAIL PROTECTED] Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User (the model representing the user) UserForm (an enrollment form for a new user) UserAction (Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the Administrative User Flag option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an Administrative User Flag field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the Administrative Flag on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
RE: Potential Security Flaw in Struts MVC
I usually just lurk on this list, but I think I'll pipe in here. I think Curt raises a valid point, and it's one of my particular gripes about the webapp paradigm (certainly not Struts in general): every action that is represented by URL is accessible if you know the right information (or can guess it). Here's an example. Let's say I have I have servlets (or JSPs, or whatever) that do things like HireEmployee, FireEmployee, AdjustWages, PayBonus, etc. Based on naming convention, if I have access to some of these functions I might very well be able to guess the names of others. So I have to build security into each of these functions, to ensure that the user is authorized to do the task. Now, for a simple app, this may not be too bad: just cut and paste the code and you're on your way. As the application grows in complexity, however (either in the number of functions that need to be validated, or the code that does the validation, or both), it becomes increasingly easy to introduce bugs into the system. The developer might miscode a particular security check. Or he might forget to add security for a newly created function. If you have a system with hundreds or thousands of secure functions, the chances of making errors increases significantly if you are duplicating code in all those places, and any mistake results in a security hole within your app. Now, what are some possible strategies for dealing with this? Well, in JSP's you could probably do includes to reuse the same physical piece of code, or in Servlets you could delegate to some kind of common security function. Neither of these situations solves the scenario however where the developer forgets to invoke the proper security measures (maybe they're not aware of the proper security for a task, or maybe they just made a mistake). The point is that even though you're using includes or calling a common authorization method (thereby reducing the amount of lines of duplicated code), you are still relying on all of the actions to make the call in the first place. If you have a system with hundreds of functions, what are the odds that as that systems grows (new functions added, security policies modified, etc) mistakes will creep in? Pretty good, in my experience. And in the webapp environment such security holes are often more accessible to the world at large. What if you could define actions as belonging to a particular master class of action. In other words, the example functions I gave above might all be a subset of MgrActions or something like that? What would really be nice would be for actions to be defined hierarchically, and to allow for validations/authorization to be performed on a parent. So for instance, rather than duplicating specific authorizations for HireEmployee, FireEmployee, AdjustWages, PayBonus, it'd be nice to just write the authorization code once for MgrActions, and know that it would automatically get applied to any of the actions that extend the MgrAction. Then when you add new actions, they would automatically inherit the security policies of all their parent actions. If you need to modify security policies, you'd only have to change the logic in one place. I have no idea how you would implement something like this in Struts (or if its even possible). In Barracuda, we were able to do this in our event model. When client requests come in, they are translated to events, and for every event that is dispatched, if that event implements a marker interface called Polymorphic, then all the Event's parent events will be dispatched first (since, after all, the target event is an instance of each of those parent events). This pattern works extremely well for implementing policies that apply to portions of an application. As the application evolves, you only have to make changes to authorization logic in one place; new actions automatically inherit their parents' policies; and if you ever need to add new policies (like say logging all the MgrAction events plus all the SrMgrAction events), all you have to do is change your event hierarchy and add new listener code for the newly defined event. This logic would then automatically apply to all events further down the chain. Like I said, this has worked very well for us in Barracuda. I have no idea how you'd apply this concept in Struts, but the pattern itself (hierarchical events/actions) should be applicable to just about any web app framework. The only limiting factor that I can think of is that in order to implement hierarchy, you'd probably have to define your actions or events as real objects, not just Strings. Anyway, I'd be curious to hear thoughts and feedback, and to know how others have approached this particular type of problem... Christian Christian Cryder [EMAIL PROTECTED] Barracuda - Open-source MVC Component Framework for Webapps http://barracuda.enhydra.org
Re: Potential Security Flaw in Struts MVC
Wouldn't the hacker have to get the new form class into the classpath of the server since all of the code runs server side? Jeff Trent wrote: That is not what my thinking was. But that could be an issue also. My concern is someone intentionally and maliciously creating a form to supply more parameters than originally intented by the developer. For instance, consider the UserForm fields: Name(available to enrollment administrative interface) Address(available to enrollment administrative interface) Phone(available to enrollment administrative interface) Email(available to enrollment administrative interface) ApprovedUserFlag(available to administrative interface only) AdministrativeUserFlag (available to administrative interface only) If a user knows your naming concention, they can write their own form to override the administrative-level fields above. - Original Message - From: Anthony Martin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 11:59 AM Subject: RE: Potential Security Flaw in Struts MVC Jeff, Are you asking if book marking a URL that contains query parameters might be a security risk? Anthony -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:37 AM To: [EMAIL PROTECTED] Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User(the model representing the user) UserForm(an enrollment form for a new user) UserAction(Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the Administrative User Flag option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an Administrative User Flag field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the Administrative Flag on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff begin:vcard n:; x-mozilla-html:FALSE org:BRIMG SRC=http://www.irista.com/logo/irista.gif;BRBRFONT Color=#80FONT SIZE=2BBringing Vision to Your Supply Chain adr:;; version:2.1 end:vcard
Suggestion for Inclusion in HTML Bean
Can I suggest to any Struts developers listening that a new form tag called "static" be added which will simply return the current form value as static text...
update database.xml
Hi all, I have a question to ask. I want to update the database.xml file and the database hashtable of the DatabaseServlet class every time the user register. So when the user logs on next time (even after the tomcat is restarted), he/she can still log on. Any idea? Thanks. Ying P.S. I already successfully updated the database in the perform function of the SaveRegistrationAction class.
RE: ActionServlet to change language ?
Title: RE: ActionServlet to change language ?
An
other method i would advise is
In
your action class just call the setLocale() passing in the parameter(language
preference)the user has selected. That way you can be assured of not
making an if-elseif-else call
-Original Message-From: Jason Chaffee
[mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 1:07
PMTo: '[EMAIL PROTECTED]'Subject: RE:
ActionServlet to change language ?
One solution is for each page to have a hidden field that
contains it's relative path. Then you can forard to that page after you
have changed the locale.
-Original Message- From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 07, 2001 5:17 AM To: [EMAIL PROTECTED] Subject:
ActionServlet to change language ?
Hi all,
I want to use a simple action to change the language in a
site, but I would like this feature to be available on
all pages of the site. I'm using a template, and the
same menu (with language selection) is included in
each page. My question is : When a visitor decide to
change the language, how could I know the URL where he
was and where I had to come back ?
In other words, how can I complete the following code ?
+ public final class ChangeLang extends Action {
public ActionForward perform(
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws IOException,
ServletException {
// Extract parameters we
will need String requested =
(String)request.getParameter( "lang" );
if( requested == null ) return
(mapping.findForward("error")); if(
requested.equalsIgnoreCase( "FR" ) ) setLocale( request, Locale.FRANCE
); if( requested.equalsIgnoreCase(
"UK" ) ) setLocale(
request, Locale.UK ); if(
requested.equalsIgnoreCase( "DE" ) ) setLocale( request, Locale.GERMAN
);
return ( ? ); }
protected void setLocale(
HttpServletRequest request, Locale locale )
{ HttpSession session =
request.getSession(false); if (session != null)
session.setAttribute(Action.LOCALE_KEY, locale); } }
+
In my strus-config.xml :
+ action-mappings action path="/ChLang"
actionClass="classes.ChangeLang" forward name="error"
path="/error.jsp"/
/action /action-mappings
+
My menu :
+ %@ taglib uri='/WEB-INF/struts-html.tld' prefix='html' %
table width="100%" tr td Select Language : html:link
page="/ChLang.do?lang=FR"FR/html:link | html:link page="/ChLang.do?lang=EN"EN/html:link
| html:link
page="/ChLang.do?lang=NL"NL/html:link | html:link page="/ChLang.do?lang=D"D/html:link
/td /tr
/table +
Thanks. -- Olivier DUCHÊNE
RE: problem with weblogic 5.1sp9 and example webapp
have to use sp9, at least on the server-side, since sp8 uses green threads on our environment, and this is too slow.  Any other suggestions?  Thanks, John -Original Message- From: JasonChaffee [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 12:10 PM To: struts-user Cc: JasonChaffee Subject: RE: problem with weblogic 5.1sp9 and example webapp Use sp8, sp9 is really, really bad. -Original Message- From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:58 AM To: [EMAIL PROTECTED] Subject: problem with weblogic 5.1sp9 and example webapp I am new to struts, and am trying to access the example webapp. I am using Weblogic 5.1 with service pack 9 installed, and have added xerces.jar to the JAVA_CLASSPATH, and the examples/WEB-INF/classes, examples/WEB-INF/lib/struts.jar listings to the WEBLOGIC_CLASSPATH (I expanded the sample from the war file)... When I try to access the webapp, I get the following stacktrace: java.lang.NoSuchMethodError    at weblogic.servlet.jsp.MyAttInfo.init(StandardTagLib.java:34)    at weblogic.servlet.jsp.StandardTagLib.processTag(StandardTagLib.java:280)    at weblogic.servlet.jsp.StandardTagLib.processTagElements(StandardTagLib.ja va:146)    at weblogic.servlet.jsp.StandardTagLib.init(StandardTagLib.java:125)    at weblogic.servlet.jsp.JspLexer.loadTagLib(JspLexer.java:95)    at weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE_BODY(JspLexer.java:3873)    at weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE(JspLexer.java:3623)    at weblogic.servlet.jsp.JspLexer.mDIRECTIVE(JspLexer.java:3484)    at weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:1817)    at weblogic.servlet.jsp.JspLexer.mTOKEN(JspLexer.java:1658)    at weblogic.servlet.jsp.JspLexer.nextToken(JspLexer.java:1548)    at weblogic.servlet.jsp.JspLexer.parse(JspLexer.java:888)    at weblogic.servlet.jsp.JspParser.doit(JspParser.java:69)    at weblogic.servlet.jsp.JspParser.parse(JspParser.java:125)    at weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:109)    at weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java:242)    at weblogic.servlet.jsp.JspStub.compilePage(JspStub.java:312)    at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:227)    at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.jav a:200)    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl. java:115)    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl. java:138)    at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContex tImpl.java:915)    at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContex tImpl.java:879)    at weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletCon textManager.java:269)    at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:3 65)    at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:253)    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129) Does anyone have any ideas about how to solve this?? Any help would be greatly appreciated. John Casey
RE: Potential Security Flaw in Struts MVC
Any thing dealing with security, (including security validation) keep it in the request scope. That way no other developer (at runtime) can access the security data. [Nanduri, Amarnath]-Original Message-From: Hogan, John [mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 1:10 PMTo: '[EMAIL PROTECTED]'Subject: RE: Potential Security Flaw in Struts MVC Wouldn't this not be a concern because the user would never be in the session on the target server? -Original Message-From: Jeff Trent [mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 11:37 AMTo: [EMAIL PROTECTED]Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User (the model representing the user) UserForm (an enrollment form for a new user) UserAction (Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the "Administrative User Flag" option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an "Administrative User Flag" field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the "Administrative Flag" on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
Re: Potential Security Flaw in Struts MVC
I can appreciate your concern. And it's always good to emphasize security concerns. But you are suggesting that I (or any developer) would write some Action that would accept this UserForm, including the sensitive admin flag, without checking as to whether the admin flag is acceptable in the application's current state. This would indeed be a casual and naive web application developer. For example, the app shouldn't pay attention to the admin flag unless the current user is already in some kind of administrative role. There are many security concerns related to web applications. I haven't actually ever found a good, consise and reasonably complete article on them. Will - Original Message - From: Jeff Trent [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 12:51 PM Subject: Re: Potential Security Flaw in Struts MVC Curt, I don't dispute what your saying. However, to the casual struts user this fact may be easily overlooked and exploited by a hacker. - jeff - Original Message - From: Curt Hagenlocher [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 12:10 PM Subject: RE: Potential Security Flaw in Struts MVC However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an Administrative User Flag field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the Administrative Flag on the user. Unless, of course, the developer makes special provisions to prevent this behavior. Creating a secure web application means that *every* HTTP request should be checked for validity. Any data that comes from the client is suspect. This is no more or less true with Struts than without it. -- Curt Hagenlocher [EMAIL PROTECTED]
Re: Potential Security Flaw in Struts MVC
depends. He would have a session if he has enrolled already... - Original Message - From: Hogan, John To: '[EMAIL PROTECTED]' Sent: Monday, May 07, 2001 1:09 PM Subject: RE: Potential Security Flaw in Struts MVC Wouldn't this not be a concern because the user would never be in the session on the target server? -Original Message-From: Jeff Trent [mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 11:37 AMTo: [EMAIL PROTECTED]Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User (the model representing the user) UserForm (an enrollment form for a new user) UserAction (Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the "Administrative User Flag" option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an "Administrative User Flag" field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the "Administrative Flag" on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
Re: Potential Security Flaw in Struts MVC
Title: RE: Potential Security Flaw in Struts MVC Beyond the scope of my brain container class (maybe in a week or so I'll know how to translate what you just said in terms of what I know) :^ - Original Message - From: Jason Chaffee To: '[EMAIL PROTECTED]' Sent: Monday, May 07, 2001 1:28 PM Subject: RE: Potential Security Flaw in Struts MVC You can easily guard against this by using simple JavaBeans in the presentation layer and having your action class do the persistant storage from you JavaBean view layer. -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 9:50 AM To: [EMAIL PROTECTED] Subject: Re: Potential Security Flaw in Struts MVC That is not what my thinking was. But that could be an issue also. My concern is someone intentionally and maliciously creating a form to supply more parameters than originally intented by the developer. For instance, consider the UserForm fields: Name (available to enrollment administrative interface) Address (available to enrollment administrative interface) Phone (available to enrollment administrative interface) Email (available to enrollment administrative interface) ApprovedUserFlag (available to administrative interface only) AdministrativeUserFlag (available to administrative interface only) If a user knows your naming concention, they can write their own form to override the administrative-level fields above. - Original Message - From: "Anthony Martin" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 11:59 AM Subject: RE: Potential Security Flaw in Struts MVC Jeff, Are you asking if book marking a URL that contains query parameters might be a security risk?Anthony -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:37 AM To: [EMAIL PROTECTED] Subject: Potential Security Flaw in Struts MVCI may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User (the model representing the user) UserForm (an enrollment form for a new user) UserAction (Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the "Administrative User Flag" option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an "Administrative User Flag" field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the "Administrative Flag" on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
RE: Suggestion/Idea for iterate tag: Iterate ResultSets
See this for remote resultsets... http://developer.java.sun.com/developer/earlyAccess/crs/ also there is a good section in Professional Java Server Programming J2EE Edition (Wrox press) Page 587 on a TableModel tag library... Lewis -Original Message- From: Mindaugas Idzelis [mailto:[EMAIL PROTECTED]] Sent: 07 May 2001 02:33 To: struts Subject: Suggestion/Idea for iterate tag: Iterate ResultSets I just thought up of an excellent idea (although, I wasn't the only one). Use the iterate tag to iterate over the rows of a resultset. The column meta data could be exposed as beans named as the column name. A bean:write operation would display the data in the column. I did a search about this topic in the mailing list archive, and I found this message: http://marc.theaimsgroup.com/?l=struts-userm=98269295229785w=2 It talk about ResultSets being tied to connections. This is not the case. ResultSets are tied to the statements that produced them, and as far as I can tell, statements are not closed when the connection is closed. Other than that, It should be easy to change the iterate tag to support resultsets. If anyone is interested in helping me extend or develop a tag for this purpose, please message me. --min
Re: Potential Security Flaw in Struts MVC
I think that this potential exploit should probably be thoroughly documented, along with potential workarounds. Last thing we want is to have Struts being tagged as being unsecure. Calvin --- David Winterfeldt [EMAIL PROTECTED] wrote: If you share a bean between two security groups, you can still have separate actions. Only an authorized user of the group could access its action. Then the non-administrative action doesn't save the administrative only field. David --- Jeff Trent [EMAIL PROTECTED] wrote: That is not what my thinking was. But that could be an issue also. My concern is someone intentionally and maliciously creating a form to supply more parameters than originally intented by the developer. For instance, consider the UserForm fields: Name(available to enrollment administrative interface) Address(available to enrollment administrative interface) Phone(available to enrollment administrative interface) Email(available to enrollment administrative interface) ApprovedUserFlag(available to administrative interface only) AdministrativeUserFlag (available to administrative interface only) If a user knows your naming concention, they can write their own form to override the administrative-level fields above. - Original Message - From: Anthony Martin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 11:59 AM Subject: RE: Potential Security Flaw in Struts MVC Jeff, Are you asking if book marking a URL that contains query parameters might be a security risk? Anthony -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:37 AM To: [EMAIL PROTECTED] Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User(the model representing the user) UserForm(an enrollment form for a new user) UserAction(Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the Administrative User Flag option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an Administrative User Flag field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the Administrative Flag on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/ __ Do You Yahoo!? Yahoo! Auctions - buy the things you want at great prices http://auctions.yahoo.com/
Re: Potential Security Flaw in Struts MVC
Christian, You kick ass! Apologies to the sensitive but that was a great explanation of a very obscure but important problem. Bryan Christian Cryder wrote: I usually just lurk on this list, but I think I'll pipe in here.
Re: Potential Security Flaw in Struts MVC
I like it! I second this request totally! I too have been involved with large scale development projects and I can relate closely to what you are saying Chris. A simple implementation could be a new derivation off of Action called SecurityAction with an abstract method called validate (not like the form validate). This validate checks to see if the action is valid for the current http request / context. If you want to become more adventurous, have a default implementation instead which uses the configuration properties. - jeff - Original Message - From: Christian Cryder [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 1:52 PM Subject: RE: Potential Security Flaw in Struts MVC I usually just lurk on this list, but I think I'll pipe in here. I think Curt raises a valid point, and it's one of my particular gripes about the webapp paradigm (certainly not Struts in general): every action that is represented by URL is accessible if you know the right information (or can guess it). Here's an example. Let's say I have I have servlets (or JSPs, or whatever) that do things like HireEmployee, FireEmployee, AdjustWages, PayBonus, etc. Based on naming convention, if I have access to some of these functions I might very well be able to guess the names of others. So I have to build security into each of these functions, to ensure that the user is authorized to do the task. Now, for a simple app, this may not be too bad: just cut and paste the code and you're on your way. As the application grows in complexity, however (either in the number of functions that need to be validated, or the code that does the validation, or both), it becomes increasingly easy to introduce bugs into the system. The developer might miscode a particular security check. Or he might forget to add security for a newly created function. If you have a system with hundreds or thousands of secure functions, the chances of making errors increases significantly if you are duplicating code in all those places, and any mistake results in a security hole within your app. Now, what are some possible strategies for dealing with this? Well, in JSP's you could probably do includes to reuse the same physical piece of code, or in Servlets you could delegate to some kind of common security function. Neither of these situations solves the scenario however where the developer forgets to invoke the proper security measures (maybe they're not aware of the proper security for a task, or maybe they just made a mistake). The point is that even though you're using includes or calling a common authorization method (thereby reducing the amount of lines of duplicated code), you are still relying on all of the actions to make the call in the first place. If you have a system with hundreds of functions, what are the odds that as that systems grows (new functions added, security policies modified, etc) mistakes will creep in? Pretty good, in my experience. And in the webapp environment such security holes are often more accessible to the world at large. What if you could define actions as belonging to a particular master class of action. In other words, the example functions I gave above might all be a subset of MgrActions or something like that? What would really be nice would be for actions to be defined hierarchically, and to allow for validations/authorization to be performed on a parent. So for instance, rather than duplicating specific authorizations for HireEmployee, FireEmployee, AdjustWages, PayBonus, it'd be nice to just write the authorization code once for MgrActions, and know that it would automatically get applied to any of the actions that extend the MgrAction. Then when you add new actions, they would automatically inherit the security policies of all their parent actions. If you need to modify security policies, you'd only have to change the logic in one place. I have no idea how you would implement something like this in Struts (or if its even possible). In Barracuda, we were able to do this in our event model. When client requests come in, they are translated to events, and for every event that is dispatched, if that event implements a marker interface called Polymorphic, then all the Event's parent events will be dispatched first (since, after all, the target event is an instance of each of those parent events). This pattern works extremely well for implementing policies that apply to portions of an application. As the application evolves, you only have to make changes to authorization logic in one place; new actions automatically inherit their parents' policies; and if you ever need to add new policies (like say logging all the MgrAction events plus all the SrMgrAction events), all you have to do is change your event hierarchy and add new listener code for the newly defined event. This logic would then automatically apply to all events further down
Re: Potential Security Flaw in Struts MVC
No, I can write a form locaally and have the action run on your server... - Original Message - From: Peter Alfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 1:56 PM Subject: Re: Potential Security Flaw in Struts MVC Wouldn't the hacker have to get the new form class into the classpath of the server since all of the code runs server side? Jeff Trent wrote: That is not what my thinking was. But that could be an issue also. My concern is someone intentionally and maliciously creating a form to supply more parameters than originally intented by the developer. For instance, consider the UserForm fields: Name(available to enrollment administrative interface) Address(available to enrollment administrative interface) Phone(available to enrollment administrative interface) Email(available to enrollment administrative interface) ApprovedUserFlag(available to administrative interface only) AdministrativeUserFlag (available to administrative interface only) If a user knows your naming concention, they can write their own form to override the administrative-level fields above. - Original Message - From: Anthony Martin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 11:59 AM Subject: RE: Potential Security Flaw in Struts MVC Jeff, Are you asking if book marking a URL that contains query parameters might be a security risk? Anthony -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:37 AM To: [EMAIL PROTECTED] Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User(the model representing the user) UserForm(an enrollment form for a new user) UserAction(Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the Administrative User Flag option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an Administrative User Flag field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the Administrative Flag on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
Re: Potential Security Flaw in Struts MVC
I think I must be missing something... I don't see how a user/hacker is going to gain access to the system if one is using security. If you route each request through a security check (realm) then you should be able to determine if the current user has access to the requested page/action. Each task should be a different action, rather than using, say, query string parameters to define an action. Then the security realm can authenticate the user before allowing the action to take place. The code is being run server side, therefore, users cannot introduce their own classes to over-ride the current form classes or actions. Am I missing something? Thanks, Pete Christian Cryder wrote: I usually just lurk on this list, but I think I'll pipe in here. I think Curt raises a valid point, and it's one of my particular gripes about the webapp paradigm (certainly not Struts in general): every action that is represented by URL is accessible if you know the right information (or can guess it). Here's an example. Let's say I have I have servlets (or JSPs, or whatever) that do things like HireEmployee, FireEmployee, AdjustWages, PayBonus, etc. Based on naming convention, if I have access to some of these functions I might very well be able to guess the names of others. So I have to build security into each of these functions, to ensure that the user is authorized to do the task. Now, for a simple app, this may not be too bad: just cut and paste the code and you're on your way. As the application grows in complexity, however (either in the number of functions that need to be validated, or the code that does the validation, or both), it becomes increasingly easy to introduce bugs into the system. The developer might miscode a particular security check. Or he might forget to add security for a newly created function. If you have a system with hundreds or thousands of secure functions, the chances of making errors increases significantly if you are duplicating code in all those places, and any mistake results in a security hole within your app. Now, what are some possible strategies for dealing with this? Well, in JSP's you could probably do includes to reuse the same physical piece of code, or in Servlets you could delegate to some kind of common security function. Neither of these situations solves the scenario however where the developer forgets to invoke the proper security measures (maybe they're not aware of the proper security for a task, or maybe they just made a mistake). The point is that even though you're using includes or calling a common authorization method (thereby reducing the amount of lines of duplicated code), you are still relying on all of the actions to make the call in the first place. If you have a system with hundreds of functions, what are the odds that as that systems grows (new functions added, security policies modified, etc) mistakes will creep in? Pretty good, in my experience. And in the webapp environment such security holes are often more accessible to the world at large. What if you could define actions as belonging to a particular master class of action. In other words, the example functions I gave above might all be a subset of MgrActions or something like that? What would really be nice would be for actions to be defined hierarchically, and to allow for validations/authorization to be performed on a parent. So for instance, rather than duplicating specific authorizations for HireEmployee, FireEmployee, AdjustWages, PayBonus, it'd be nice to just write the authorization code once for MgrActions, and know that it would automatically get applied to any of the actions that extend the MgrAction. Then when you add new actions, they would automatically inherit the security policies of all their parent actions. If you need to modify security policies, you'd only have to change the logic in one place. I have no idea how you would implement something like this in Struts (or if its even possible). In Barracuda, we were able to do this in our event model. When client requests come in, they are translated to events, and for every event that is dispatched, if that event implements a marker interface called Polymorphic, then all the Event's parent events will be dispatched first (since, after all, the target event is an instance of each of those parent events). This pattern works extremely well for implementing policies that apply to portions of an application. As the application evolves, you only have to make changes to authorization logic in one place; new actions automatically inherit their parents' policies; and if you ever need to add new policies (like say logging all the MgrAction events plus all the SrMgrAction events), all you have to do is change your event hierarchy and add new listener code for the newly defined event. This logic would then automatically apply to all events further down the chain. Like I
RE: Potential Security Flaw in Struts MVC
You can also restrict access in a webapp through the web.xml. security-constraint web-resource-collection web-resource-name adminPages /web-resource-name url-pattern /admin/* /url-pattern /web-resource-collection auth-constraint role-name Administrative /role-name /auth-constraint /security-constraint Then if you put all your administrative actions and JSP pages under this URL, the framework will check if you are in the Administrative role before you can access a page. This is going to be added to Struts in the 1.1 release. Role-Based Action Execution. Add the ability to require the current user to be in a particular security role before they can execute a particular action. David --- Christian Cryder [EMAIL PROTECTED] wrote: I usually just lurk on this list, but I think I'll pipe in here. I think Curt raises a valid point, and it's one of my particular gripes about the webapp paradigm (certainly not Struts in general): every action that is represented by URL is accessible if you know the right information (or can guess it). Here's an example. Let's say I have I have servlets (or JSPs, or whatever) that do things like HireEmployee, FireEmployee, AdjustWages, PayBonus, etc. Based on naming convention, if I have access to some of these functions I might very well be able to guess the names of others. So I have to build security into each of these functions, to ensure that the user is authorized to do the task. Now, for a simple app, this may not be too bad: just cut and paste the code and you're on your way. As the application grows in complexity, however (either in the number of functions that need to be validated, or the code that does the validation, or both), it becomes increasingly easy to introduce bugs into the system. The developer might miscode a particular security check. Or he might forget to add security for a newly created function. If you have a system with hundreds or thousands of secure functions, the chances of making errors increases significantly if you are duplicating code in all those places, and any mistake results in a security hole within your app. Now, what are some possible strategies for dealing with this? Well, in JSP's you could probably do includes to reuse the same physical piece of code, or in Servlets you could delegate to some kind of common security function. Neither of these situations solves the scenario however where the developer forgets to invoke the proper security measures (maybe they're not aware of the proper security for a task, or maybe they just made a mistake). The point is that even though you're using includes or calling a common authorization method (thereby reducing the amount of lines of duplicated code), you are still relying on all of the actions to make the call in the first place. If you have a system with hundreds of functions, what are the odds that as that systems grows (new functions added, security policies modified, etc) mistakes will creep in? Pretty good, in my experience. And in the webapp environment such security holes are often more accessible to the world at large. What if you could define actions as belonging to a particular master class of action. In other words, the example functions I gave above might all be a subset of MgrActions or something like that? What would really be nice would be for actions to be defined hierarchically, and to allow for validations/authorization to be performed on a parent. So for instance, rather than duplicating specific authorizations for HireEmployee, FireEmployee, AdjustWages, PayBonus, it'd be nice to just write the authorization code once for MgrActions, and know that it would automatically get applied to any of the actions that extend the MgrAction. Then when you add new actions, they would automatically inherit the security policies of all their parent actions. If you need to modify security policies, you'd only have to change the logic in one place. I have no idea how you would implement something like this in Struts (or if its even possible). In Barracuda, we were able to do this in our event model. When client requests come in, they are translated to events, and for every event that is dispatched, if that event implements a marker interface called Polymorphic, then all the Event's parent events will be dispatched first (since, after all, the target event is an instance of each of those parent events). This pattern works extremely well for implementing policies that apply to portions of an application. As the application evolves, you only have to make changes to authorization logic in one place; new actions automatically inherit their parents' policies; and if you ever need to add new policies (like say logging all the MgrAction events plus all the SrMgrAction events), all you have to do is change your event
Re: Potential Security Flaw in Struts MVC
This is a bit off subject but since I'm in commentary-mode today I'll also mention it. I need to give some background here first: As I mentioned in an earlier message, I worked on a fairly large web project (several million hits per day, tens of thousand user sessions per day). The app runs on 7 iPlanet web servers (Sun 420R) and 3 application servers (Sun 4500s) (formerly called Netscape Application Server - aka NAS). NAS load balances sessions requests between the app servers in real time. As a result, Netscape advocates small as possible sessions sizes since session information is constantly being i/o'ed across the app servers. What led me to Struts initially was the belief that Struts can help me take the drudgery out of creating multi-page wizards (very prevalent in the app). However, I was a little dismayed to learn that in order to accomplish this I need to rely heavily on session scoped (not request) beans. This would cause the app servers to spend an enormous amount of time communicating with one another. Therefore, if I haven't reached my quota today, I'd like to suggest to management that there is a bean property (or something) that results in form fields being propogated accross multiple pages of my request/form and are managed using hidden variables alone. This would be an alternative to using session scope but would accomplish the same thing. Again, all comments are welcome... -jeff - Original Message - From: Christian Cryder [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 1:52 PM Subject: RE: Potential Security Flaw in Struts MVC I usually just lurk on this list, but I think I'll pipe in here. I think Curt raises a valid point, and it's one of my particular gripes about the webapp paradigm (certainly not Struts in general): every action that is represented by URL is accessible if you know the right information (or can guess it). Here's an example. Let's say I have I have servlets (or JSPs, or whatever) that do things like HireEmployee, FireEmployee, AdjustWages, PayBonus, etc. Based on naming convention, if I have access to some of these functions might very well be able to guess the names of others. So I have to build security into each of these functions, to ensure that the user is authorized to do the task. Now, for a simple app, this may not be too bad: just cut and paste the code and you're on your way. As the application grows in complexity, however (either in the number of functions that need to be validated, or the code that does the validation, or both), it becomes increasingly easy to introduce bugs into the system. The developer might miscode a particular security check. Or he might forget to add security for a newly created function. If you have a system with hundreds or thousands of secure functions, the chances of making errors increases significantly if you are duplicating code in all those places, and any mistake results in a security hole within your app. Now, what are some possible strategies for dealing with this? Well, in JSP's you could probably do includes to reuse the same physical piece of code, or in Servlets you could delegate to some kind of common security function. Neither of these situations solves the scenario however where the developer forgets to invoke the proper security measures (maybe they're not aware of the proper security for a task, or maybe they just made a mistake). The point is that even though you're using includes or calling a common authorization method (thereby reducing the amount of lines of duplicated code), you are still relying on all of the actions to make the call in the first place. If you have a system with hundreds of functions, what are the odds that as that systems grows (new functions added, security policies modified, etc) mistakes will creep in? Pretty good, in my experience. And in the webapp environment such security holes are often more accessible to the world at large. What if you could define actions as belonging to a particular master class of action. In other words, the example functions I gave above might all be a subset of MgrActions or something like that? What would really be nice would be for actions to be defined hierarchically, and to allow for validations/authorization to be performed on a parent. So for instance, rather than duplicating specific authorizations for HireEmployee, FireEmployee, AdjustWages, PayBonus, it'd be nice to just write the authorization code once for MgrActions, and know that it would automatically get applied to any of the actions that extend the MgrAction. Then when you add new actions, they would automatically inherit the security policies of all their parent actions. If you need to modify security policies, you'd only have to change the logic in one place. I have no idea how you would implement something like this in Struts (or if its even possible). In Barracuda, we were able to do this
RE: Problems with Struts example in Netscape 4.75
I have previously experienced very slow form processing under Netscape 4.76 using Tomcat 3.1. We were not using Struts, but rather our own MVC model at the time. I even created a test case with only a servlet to post to and it took a few seconds for the servlet to get the response. This behavior was only under Netscape and did not appear in the newest Netscape release. I tested the post by putting a system.out.println as the first item in the servlet body. I would click the submit button in Netscape and time it. It usually took 3 seconds before I would see the system.out.println. In any version of IE and in the latest Netscape release, the response time was very quick (500 ms). I would be interested in testing this application under Tomcat 3.2 now. -Original Message- From: Tobias Meyer [SMTP:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 12:03 PM To: [EMAIL PROTECTED] Subject: Problems with Struts example in Netscape 4.75 Hi! I'm just wondering if anybody else encountered problems with Netscape and the Struts example. The POST method (Register for the MailReader Demonstration Application) seems to take forever until it gives back a response (however clicking on the browser's title-bar immediately solves this problem). I'm not sure if this is a struts problem because I found some related bugs in the tomcat bug-database (which has been fixed in tomcat 3.2). I had problems reproducing it with a simple servlet (non using struts). My Environment: - Tomcat 3.2.1 - Struts 1.0 beta - Netscape 4.75 en Thanks in advance, Tobias
RE: Potential Security Flaw in Struts MVC
I think you are trying to make things too hard, you could handle this relatively simple in two different ways: 1. You could inherit your actions from a super class that simple check to see if the user is logged our has sufficient privileges. And add a super(request) method as the first line of the action. 2. Have a security class that is called in the first line, maybe from an action interface, and check the login and privs that way. The security class could have a call to a session bean that holds all the security info. -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 2:47 PM To: [EMAIL PROTECTED] Subject: Re: Potential Security Flaw in Struts MVC Beyond the scope of my brain container class (maybe in a week or so I'll know how to translate what you just said in terms of what I know) :^ - Original Message - From: Jason Chaffee mailto:[EMAIL PROTECTED] To: '[EMAIL PROTECTED]' mailto:'[EMAIL PROTECTED]' Sent: Monday, May 07, 2001 1:28 PM Subject: RE: Potential Security Flaw in Struts MVC You can easily guard against this by using simple JavaBeans in the presentation layer and having your action class do the persistant storage from you JavaBean view layer. -Original Message- From: Jeff Trent [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Monday, May 07, 2001 9:50 AM To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Subject: Re: Potential Security Flaw in Struts MVC That is not what my thinking was. But that could be an issue also. My concern is someone intentionally and maliciously creating a form to supply more parameters than originally intented by the developer. For instance, consider the UserForm fields: Name(available to enrollment administrative interface) Address(available to enrollment administrative interface) Phone(available to enrollment administrative interface) Email(available to enrollment administrative interface) ApprovedUserFlag(available to administrative interface only) AdministrativeUserFlag (available to administrative interface only) If a user knows your naming concention, they can write their own form to override the administrative-level fields above. - Original Message - From: Anthony Martin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 11:59 AM Subject: RE: Potential Security Flaw in Struts MVC Jeff, Are you asking if book marking a URL that contains query parameters might be a security risk? Anthony -Original Message- From: Jeff Trent [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Monday, May 07, 2001 8:37 AM To: [EMAIL PROTECTED] Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User(the model representing the user) UserForm(an enrollment form for a new user) UserAction(Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the Administrative User Flag option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an Administrative User Flag field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the Administrative Flag on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
destroy() of DatabaseServlet
Hi All, I noticed that when the tomcat shuts down, it does NOT call the destroy() method of the DatabaseServlet class. How to let the destroy() method get called when the server shuts down? Thanks. Ying
Struts power point presentation
Hi, Someone had previously posted a power point presentation to the list (Struts overview). Is it still available somewhere ? Thanks for any info. -- Nick
RE: problem with weblogic 5.1sp9 and example webapp
Title: RE: problem with weblogic 5.1sp9 and example webapp I hope you are aware that sp9 has some serious bugs and if you are counting on it following the servlet specification, well, your Web apps won't work correctly. In fact we found that sp9 loses session scope objects. If you must use weblogic 5.1 and you must use sp9, then I would suggest trying to get support from BEA, but I warn you this is a difficult task because they don't understand the servlet specification very well... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 11:27 AM To: [EMAIL PROTECTED] Subject: RE: problem with weblogic 5.1sp9 and example webapp have to use sp9, at least on the server-side, since sp8 uses green threads on our environment, and this is too slow.  Any other suggestions?  Thanks, John -Original Message- From: JasonChaffee [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 12:10 PM To: struts-user Cc: JasonChaffee Subject: RE: problem with weblogic 5.1sp9 and example webapp Use sp8, sp9 is really, really bad. -Original Message- From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:58 AM To: [EMAIL PROTECTED] Subject: problem with weblogic 5.1sp9 and example webapp I am new to struts, and am trying to access the example webapp. I am using Weblogic 5.1 with service pack 9 installed, and have added xerces.jar to the JAVA_CLASSPATH, and the examples/WEB-INF/classes, examples/WEB-INF/lib/struts.jar listings to the WEBLOGIC_CLASSPATH (I expanded the sample from the war file)... When I try to access the webapp, I get the following stacktrace: java.lang.NoSuchMethodError    at weblogic.servlet.jsp.MyAttInfo.init(StandardTagLib.java:34)    at weblogic.servlet.jsp.StandardTagLib.processTag(StandardTagLib.java:280)    at weblogic.servlet.jsp.StandardTagLib.processTagElements(StandardTagLib.ja va:146)    at weblogic.servlet.jsp.StandardTagLib.init(StandardTagLib.java:125)    at weblogic.servlet.jsp.JspLexer.loadTagLib(JspLexer.java:95)    at weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE_BODY(JspLexer.java:3873)    at weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE(JspLexer.java:3623)    at weblogic.servlet.jsp.JspLexer.mDIRECTIVE(JspLexer.java:3484)    at weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:1817)    at weblogic.servlet.jsp.JspLexer.mTOKEN(JspLexer.java:1658)    at weblogic.servlet.jsp.JspLexer.nextToken(JspLexer.java:1548)    at weblogic.servlet.jsp.JspLexer.parse(JspLexer.java:888)    at weblogic.servlet.jsp.JspParser.doit(JspParser.java:69)    at weblogic.servlet.jsp.JspParser.parse(JspParser.java:125)    at weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:109)    at weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java:242)    at weblogic.servlet.jsp.JspStub.compilePage(JspStub.java:312)    at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:227)    at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.jav a:200)    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl. java:115)    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl. java:138)    at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContex tImpl.java:915)    at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContex tImpl.java:879)    at weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletCon textManager.java:269)    at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:3 65)    at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:253)    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129) Does anyone have any ideas about how to solve this?? Any help would be greatly appreciated. John Casey
Re: Potential Security Flaw in Struts MVC
Sure. You could create a jsp page that had the fields you would like, and even call off a remote action from your own page. However, if I route my actions through a security realm, then the requested action will be denied because the current user is not logged in. Or.. If the would be hacker is actualy a valid user on the system and has a username/passsword, and he trys send his own page (along with additional fields) it will still be caught by the secuirty realm. The danger would exist if either form fields, or query string parameters were being used as an action flag. If the view, update, add, delete are different actions, then the user will be required to have a valid login before the action will even be executed. Pete Jeff Trent wrote: No, I can write a form locaally and have the action run on your server... - Original Message - From: Peter Alfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 1:56 PM Subject: Re: Potential Security Flaw in Struts MVC Wouldn't the hacker have to get the new form class into the classpath of the server since all of the code runs server side? Jeff Trent wrote: That is not what my thinking was. But that could be an issue also. My concern is someone intentionally and maliciously creating a form to supply more parameters than originally intented by the developer. For instance, consider the UserForm fields: Name(available to enrollment administrative interface) Address(available to enrollment administrative interface) Phone(available to enrollment administrative interface) Email(available to enrollment administrative interface) ApprovedUserFlag(available to administrative interface only) AdministrativeUserFlag (available to administrative interface only) If a user knows your naming concention, they can write their own form to override the administrative-level fields above. - Original Message - From: Anthony Martin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 11:59 AM Subject: RE: Potential Security Flaw in Struts MVC Jeff, Are you asking if book marking a URL that contains query parameters might be a security risk? Anthony -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:37 AM To: [EMAIL PROTECTED] Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User(the model representing the user) UserForm(an enrollment form for a new user) UserAction(Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the Administrative User Flag option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an Administrative User Flag field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the Administrative Flag on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff begin:vcard n:; x-mozilla-html:FALSE org:BRIMG SRC=http://www.irista.com/logo/irista.gif;BRBRFONT Color=#80FONT SIZE=2BBringing Vision to Your Supply Chain adr:;; version:2.1 end:vcard
RE: Potential Security Flaw in Struts MVC
At 12:17 PM 5/7/2001 -0700, you wrote: Role-Based Action Execution. Add the ability to require the current user to be in a particular security role before they can execute a particular action. I just wanted to pipe in here because we're integrating Struts into our stuff (Slowly!) The Expresso Framework http://www.jcorporate.com/ tackled this problem by creating a DB Security matrix. Each action in the controller is automatically registered with a security table and the admin can declare which user groups can access which action, as well as which permissions to access which database tables. It's done pretty transparently to the programmer. Hopefully, we'll actually have Struts integrated within the next .1 release. [People are building bridge classes as I speak], so maybe the security model in there can help somebody. -Mike
RE: unsubscribe ... please!!!!
Please unsubscribe me, email id [EMAIL PROTECTED] Thanks, Raju -Original Message- From: Siping Liu [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 02, 2001 01:12 PM To: [EMAIL PROTECTED] Subject: unsubscribe ... please please unsubscribe me. thanks,
RE: Components problem: Unable to convert a String to java.lang.Object for attribute content
I was also using tomcat 3.2.1. I just upgraded from JDK 1.2 to 1.3, and that seems to have solved the problem. -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW/ 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message- From: Cedric Dumoulin [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 02, 2001 4:55 AM To: [EMAIL PROTECTED] Subject: Re: Components problem: Unable to convert a String to java.lang.Object for attribute content Hi Tim, Which web server do you use ? I have check a similar example as yours on my web server (tomcat 3.2.1), and it works fine with latest Components distribution. I have already encountered the error message Unable to convert a String to java.lang.Object ... on server like weblogic 5.xx. A solution is to remove the method void setContent( Object value ) method in class taglib.commponents.PutTag.java and recompile Components. Using ant and the provided build.xml file should work if you set build.properties appropriately. Contact me in case of trouble. Cedric Tim Moore wrote: I'm trying to figure out the Components Library extension to Struts. I've got a simple JSP: %@ taglib uri=/WEB-INF/struts-html.tld prefix=html % %@ taglib uri=/WEB-INF/components.tld prefix=template % html:html head titleContent Form/title /head body bgcolor=white html:errors/ html:form name=testForm action=saveContent.do type=blackboard.presentation.common.TestForm template:insert template=/contentForm.jsp template:put name=labelcontent=Text: direct=true/ template:put name=property content=contentForm direct=true/ /template:insert table border=0 width=100% cellpadding=5 cellspacing=0 tr td width=10 align=left valign=topimg src=/images/spacer.gif alt= width=10 height=1 border=0/td td align=righthtml:cancel/ html:submit//td /tr /table /html:form /body /html:html When I try to hit the page, I get this error: Error: 500 Location: /sleepyweasel/content.jsp Internal Servlet Error: org.apache.jasper.compiler.CompileException: D:\jakarta-tomcat-3.2.1\webapps\sleepyweasel\content.jsp(16,8) Unable to convert a String to java.lang.Object for attribute content at org.apache.jasper.compiler.TagBeginGenerator.convertString(Tag BeginGenerator .java:271) at org.apache.jasper.compiler.TagBeginGenerator.generateSetters(C ompiled Code) at org.apache.jasper.compiler.TagBeginGenerator.generateServiceMe thodStatements (TagBeginGenerator.java:291) at org.apache.jasper.compiler.TagBeginGenerator.generate(TagBegin Generator.java :360) at org.apache.jasper.compiler.JspParseEventListener$GeneratorWrap per.generate(C ompiled Code) at org.apache.jasper.compiler.JspParseEventListener.generateAll(C ompiled Code) at org.apache.jasper.compiler.JspParseEventListener.endPageProces sing(JspParseE ventListener.java:175) at org.apache.jasper.compiler.Compiler.compile(Compiled Code) at org.apache.jasper.servlet.JspServlet.doLoadJSP(JspServlet.java:462) at org.apache.jasper.servlet.JasperLoader12.loadJSP(JasperLoader1 2.java:146) at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:433) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfN ecessary(JspSe rvlet.java:152) at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service (JspServlet.ja va:164) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet .java:318) at org.apache.jasper.servlet.JspServlet.service(Compiled Code) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper .java:404) at org.apache.tomcat.core.Handler.service(Handler.java:286) at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372) at org.apache.tomcat.core.ContextManager.internalService(ContextM anager.java:79 7) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:743) at org.apache.tomcat.service.http.HttpConnectionHandler.processCo nnection(HttpC onnectionHandler.java:210) at org.apache.tomcat.service.TcpWorkerThread.runIt(Compiled Code) at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(Compiled Code) at java.lang.Thread.run(Thread.java:479) Can Cedric or anyone shed some light? My page seems straightforward enough, and it seemed to work OK with standard Struts templates, but I need to use some advanced features in the contentForm.jsp that require
RE: Potential Security Flaw in Struts MVC
I think I must be missing something... I don't see how a user/hacker is going to gain access to the system if one is using security. If you route each request through a security check (realm) then you should be able to determine if the current user has access to the requested page/action. Am I missing something? Not really. Except that a lot of applications may implement a finer level of security for which the realm check is inconvenient. For instance, I've got a query screen on an inventory management app that allows a user to report on transactions for inventory belonging to that user. The administrator can run the query for any user in the system. I don't want two separate screens for this capability. My solution: The form has an Owner field that is only visible for administrative users. The value is submitted as an HTTP request parameter. In order to prevent non- administrative users from submitting this parameter, I simply don't read its value from the HTTP request if the user doesn't have that right. When thinking about security, it's much more important to think in terms of HTTP requests than Struts forms. Assume that the request can contain anything -- legal or not. -- Curt Hagenlocher [EMAIL PROTECTED]
RE: Problems with Struts example in Netscape 4.75
Hi, I dont know whether this is relevant or not. This is what I found out. when ever I post something to tomcat server, and the action is a JSP page(just modified, not compiled yet). It always used to take a minute or more. Then I opened up NT Task manager, amazingly Netscape was using 99% of the CPU time waiting for the response. And tomcat used to get just 1% of CPU time. Thats the reason it was taking lot of time to respond back. However if the request was made from another box, it was OK. (I tried both Netscape 4.72 and 4.76) HTH sudhi -Original Message- From: Matthew Fowkes [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 3:35 PM To: '[EMAIL PROTECTED]' Subject: RE: Problems with Struts example in Netscape 4.75 I have previously experienced very slow form processing under Netscape 4.76 using Tomcat 3.1. We were not using Struts, but rather our own MVC model at the time. I even created a test case with only a servlet to post to and it took a few seconds for the servlet to get the response. This behavior was only under Netscape and did not appear in the newest Netscape release. I tested the post by putting a system.out.println as the first item in the servlet body. I would click the submit button in Netscape and time it. It usually took 3 seconds before I would see the system.out.println. In any version of IE and in the latest Netscape release, the response time was very quick (500 ms). I would be interested in testing this application under Tomcat 3.2 now. -Original Message- From: Tobias Meyer [SMTP:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 12:03 PM To: [EMAIL PROTECTED] Subject:Problems with Struts example in Netscape 4.75 Hi! I'm just wondering if anybody else encountered problems with Netscape and the Struts example. The POST method (Register for the MailReader Demonstration Application) seems to take forever until it gives back a response (however clicking on the browser's title-bar immediately solves this problem). I'm not sure if this is a struts problem because I found some related bugs in the tomcat bug-database (which has been fixed in tomcat 3.2). I had problems reproducing it with a simple servlet (non using struts). My Environment: - Tomcat 3.2.1 - Struts 1.0 beta - Netscape 4.75 en Thanks in advance, Tobias
Re: Potential Security Flaw in Struts MVC
A basic problem with most web development is that people arebuilding security into their applications. It should be handled outside of the application. You can have your application work in conjunction with an external security mechanism for more granular control but I the security mechanism should be external to the application for the most part. You could usefor example one of the authorization and access modules for apache. Then when you create your applicationyou can create specific *protected* URLs for say an admin area. Then only the person that is logged into the security mechanism with the proper *authorization* can access that URL (or one that contains that URL and parameters being passed to it in the URL). Security needs to be considered when building the applications but trying to build it into the application is a big mistake. A big reason to not build it into the app is that as your security requirements change you invariably have to make code changes to your application. By using an external mechanism you just change the rules governing the authorization and access control usually without any code changes to your app. - Original Message - From: Jeff Trent To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 6:37 PM Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User (the model representing the user) UserForm (an enrollment form for a new user) UserAction (Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the "Administrative User Flag" option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an "Administrative User Flag" field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the "Administrative Flag" on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
Re: Potential Security Flaw in Struts MVC
Either you are misunderstanding Struts, or I am misunderstanding you. Struts will populate your UserForm for you, prior to your UserAction being called. However, it is your responsibility to, within UserAction, copy the values from UserForm to User. Bryan Jeff Trent wrote: 00bd01c0d728$40864960$6401a8c0@PROVIDENCE"> Bryan, This is good advice. However, I thought the beans are populated off of the request outside of the control of my Action class derivation. Therefore, copyProperties() doesn't pertain. - jeff - Original Message - From: BryanField-Elliot To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 1:14 PM Subject: Re: Potential Security Flaw inStruts MVC There is a security risk here as you describe, if (and only if)you are using a generic introspection-based function (like Struts'PropertyUtils.copyBean) to copy the values from the UserForm object to theUser object. There are several ways to avoid this -- 1. Don't put anadmin flag "setter" method in your User class. 2. In UserAction, don't usethe generic bean copy utility -- instead, manually copy the values, excludingthe admin flag. 3. As a smarter alternative to #2, don't use a generic beancopy utility -- instead, write an intelligent copy function in the User class,which "knows" that it's copying FROM a UserForm, TO a User, and therefore,skip the copying of the Admin flag. Bryan Jeff Trentwrote: 002501c0d70b$9df009a0$6401a8c0@PROVIDENCE" type="cite"> I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User (the model representing the user) UserForm (an enrollment form for a new user) UserAction (Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the "Administrative User Flag" option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an "Administrative User Flag" field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the "Administrative Flag" on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
logic:iterate tag
Can someone explain me about property parameter in the logic:iterate tag? I have something like below and this works fine. but I have seen in struts example where property parameter is alos used: e.g. logic:iterate id=subscription name=user property=subscriptions in this line I know name=user is an object, id=subscription is a bean but i can not understand property=subscriptions what is this and from where it came? any good explanation would be highly appericated... === %java.util.ArrayList list = new java.util.ArrayList(); list.add(new LabelValueBean(ONE,1)); list.add(new LabelValueBean(TWO,2)); list.add(new LabelValueBean(THREE,3)); list.add(new LabelValueBean(FOUR,4)); list.add(new LabelValueBean(FIVE,5)); pageContext.setAttribute(list,list,PageContext.PAGE_SCOPE); % logic:iterate id=MyList name=list html:checkbox property=userAction/ bean:write name = MyList property=label/ bean:write name = MyList property=value/ /br /logic:iterate
Re: Potential Security Flaw in Struts MVC
True, the security realm validates if the request is legal. However, if the uderlying model objects are shared (User and UserForm objects in my example) for both admin and user level forms, then the request could be manipulated to set other fields beyond what was exposed for the normal user because struts takes each name, value pair in the request and calls the appropriate setter in the form for that name. Listen, it doesn't really matter. Its highly unlikely anybody can exploit this so I'm going to drop the issue. I don't want to appear to be a flame here. - jeff - Original Message - From: Peter Alfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 4:14 PM Subject: Re: Potential Security Flaw in Struts MVC Sure. You could create a jsp page that had the fields you would like, and even call off a remote action from your own page. However, if I route my actions through a security realm, then the requested action will be denied because the current user is not logged in. Or.. If the would be hacker is actualy a valid user on the system and has a username/passsword, and he trys send his own page (along with additional fields) it will still be caught by the secuirty realm. The danger would exist if either form fields, or query string parameters were being used as an action flag. If the view, update, add, delete are different actions, then the user will be required to have a valid login before the action will even be executed. Pete Jeff Trent wrote: No, I can write a form locaally and have the action run on your server... - Original Message - From: Peter Alfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 1:56 PM Subject: Re: Potential Security Flaw in Struts MVC Wouldn't the hacker have to get the new form class into the classpath of the server since all of the code runs server side? Jeff Trent wrote: That is not what my thinking was. But that could be an issue also. My concern is someone intentionally and maliciously creating a form to supply more parameters than originally intented by the developer. For instance, consider the UserForm fields: Name(available to enrollment administrative interface) Address(available to enrollment administrative interface) Phone(available to enrollment administrative interface) Email(available to enrollment administrative interface) ApprovedUserFlag(available to administrative interface only) AdministrativeUserFlag (available to administrative interface only) If a user knows your naming concention, they can write their own form to override the administrative-level fields above. - Original Message - From: Anthony Martin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 11:59 AM Subject: RE: Potential Security Flaw in Struts MVC Jeff, Are you asking if book marking a URL that contains query parameters might be a security risk? Anthony -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:37 AM To: [EMAIL PROTECTED] Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User(the model representing the user) UserForm(an enrollment form for a new user) UserAction(Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the Administrative User Flag option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an Administrative User Flag field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the Administrative Flag on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not
Re: Potential Security Flaw in Struts MVC
We are doing something very similar. We are using the jaas security to map each action to a permission. This way, each user is mapped to the actions that he/she is allowed to perform. Each request is routed through a security check to verify that the currently logged in user has permissions to this action. Pete Michael Rimov wrote: At 12:17 PM 5/7/2001 -0700, you wrote: Role-Based Action Execution. Add the ability to require the current user to be in a particular security role before they can execute a particular action. I just wanted to pipe in here because we're integrating Struts into our stuff (Slowly!) The Expresso Framework http://www.jcorporate.com/ tackled this problem by creating a DB Security matrix. Each action in the controller is automatically registered with a security table and the admin can declare which user groups can access which action, as well as which permissions to access which database tables. It's done pretty transparently to the programmer. Hopefully, we'll actually have Struts integrated within the next .1 release. [People are building bridge classes as I speak], so maybe the security model in there can help somebody. -Mike begin:vcard n:; x-mozilla-html:FALSE org:BRIMG SRC=http://www.irista.com/logo/irista.gif;BRBRFONT Color=#80FONT SIZE=2BBringing Vision to Your Supply Chain adr:;; version:2.1 end:vcard
RE: problem with weblogic 5.1sp9 and example webapp
I'll have to check into that...thanks for the heads-up.  John -Original Message- From: JasonChaffee [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 3:08 PM To: struts-user Cc: JasonChaffee Subject: RE: problem with weblogic 5.1sp9 and example webapp I hope you are aware that sp9 has some serious bugs and if you are counting on it following the servlet specification, well, your Web apps won't work correctly. In fact we found that sp9 loses session scope objects. If you must use weblogic 5.1 and you must use sp9, then I would suggest trying to get support from BEA, but I warn you this is a difficult task because they don't understand the servlet specification very well... -Original Message- From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 11:27 AM To: [EMAIL PROTECTED] Subject: RE: problem with weblogic 5.1sp9 and example webapp have to use sp9, at least on the server-side, since sp8 uses green threads on our environment, and this is too slow.  Any other suggestions?  Thanks, John -Original Message- From: JasonChaffee [ mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 12:10 PM To: struts-user Cc: JasonChaffee Subject: RE: problem with weblogic 5.1sp9 and example webapp Use sp8, sp9 is really, really bad. -Original Message- From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:58 AM To: [EMAIL PROTECTED] Subject: problem with weblogic 5.1sp9 and example webapp I am new to struts, and am trying to access the example webapp. I am using Weblogic 5.1 with service pack 9 installed, and have added xerces.jar to the JAVA_CLASSPATH, and the examples/WEB-INF/classes, examples/WEB-INF/lib/struts.jar listings to the WEBLOGIC_CLASSPATH (I expanded the sample from the war file)... When I try to access the webapp, I get the following stacktrace: java.lang.NoSuchMethodError    at weblogic.servlet.jsp.MyAttInfo.init(StandardTagLib.java:34)    at weblogic.servlet.jsp.StandardTagLib.processTag(StandardTagLib.java:280)    at weblogic.servlet.jsp.StandardTagLib.processTagElements(StandardTagLib.ja  va:146)    at weblogic.servlet.jsp.StandardTagLib.init(StandardTagLib.java:125)    at weblogic.servlet.jsp.JspLexer.loadTagLib(JspLexer.java:95)    at weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE_BODY(JspLexer.java:3873)     at weblogic.servlet.jsp.JspLexer.mTAGLIB_DIRECTIVE(JspLexer.java:3623)    at weblogic.servlet.jsp.JspLexer.mDIRECTIVE(JspLexer.java:3484)    at weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:1817)    at weblogic.servlet.jsp.JspLexer.mTOKEN(JspLexer.java:1658)    at weblogic.servlet.jsp.JspLexer.nextToken(JspLexer.java:1548)    at weblogic.servlet.jsp.JspLexer.parse(JspLexer.java:888)    at weblogic.servlet.jsp.JspParser.doit(JspParser.java:69)    at weblogic.servlet.jsp.JspParser.parse(JspParser.java:125)    at weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:109)    at weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java:242)    at weblogic.servlet.jsp.JspStub.compilePage(JspStub.java:312)    at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:227)    at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.jav  a:200)    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.  java:115)    at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.  java:138)    at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContex  tImpl.java:915)    at weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContex  tImpl.java:879)    at weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletCon  textManager.java:269)    at weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:3  65)    at weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:253)    at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129) Does anyone have any ideas about how to solve this?? Any help would be greatly appreciated. John Casey
Re: Potential Security Flaw in Struts MVC
Ah, this maybe a problem in the way I've adapted
Struts. I reflect all UserForm method calls directly into the contained
User object owned by the UserForm. So for instance, I have
public class UserForm extends
ActionsForm
{
protected User
user;
...
public String
getName()
{
return
user.getName();
}
public void setName(String
name)
{
user.setName(name);
}
...
}
Now can you begin to see my original concern?
Maybe I need to separate the model from the form a little more than what I
have.
- jeff
- Original Message -
From:
Bryan
Field-Elliot
To: [EMAIL PROTECTED]
Sent: Monday, May 07, 2001 4:38 PM
Subject: Re: Potential Security Flaw in
Struts MVC
Either you are misunderstanding Struts, or I am
misunderstanding you.Struts will populate your UserForm for you, prior
to your UserAction being called. However, it is your responsibility to, within
UserAction, copy the values from UserForm to
User.BryanJeff Trent wrote:
00bd01c0d728$40864960$6401a8c0@PROVIDENCE"
type="cite">
Bryan,
This is good advice. However, I thought
the beans are populated off of the request outside of the control of my
Action class derivation. Therefore, copyProperties() doesn't
pertain.
- jeff
-
Original Message -
From: Bryan
Field-Elliot
To:
[EMAIL PROTECTED]
Sent:
Monday, May 07, 2001 1:14 PM
Subject:
Re: Potential Security Flaw in Struts MVC
There is a security risk here as you describe, if (and only
if) you are using a generic introspection-based function (like Struts'
PropertyUtils.copyBean) to copy the values from the UserForm object to the
User object. There are several ways to avoid this --1. Don't put
an admin flag "setter" method in your User class.2. In UserAction,
don't use the generic bean copy utility -- instead, manually copy the
values, excluding the admin flag.3. As a smarter alternative to #2,
don't use a generic bean copy utility -- instead, write an intelligent
copy function in the User class, which "knows" that it's copying FROM a
UserForm, TO a User, and therefore, skip the copying of the Admin
flag.BryanJeff Trent wrote:
002501c0d70b$9df009a0$6401a8c0@PROVIDENCE"
type="cite">
I may be wrong about this (only been
working w/ Struts for a week now). But I do see a potential
security flaw in struts that I would like to hear from others
regarding.
Consider a simple set of struts classes
that represent a user in a system. You would probably have classes that
look something like this:
User
(the model
representing the user)
UserForm (an enrollment form for a
new user)
UserAction (Saves the UserForm
information to db, etc)
The User class would have accessors and
modifiers like getFirstName(), setFirstName(),
getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The
basic implementation of the UserForm is to take the UI form data,
introspect the beans, and call the correct modifier of the UserForm bean
based on the fields contained within the UI submission/form. A
developer of course would not expose the "Administrative User Flag"
option on the UI for enrollment (that would be found possibly in some
other administrative-level module). However, if someone is
familiar with the db schema and the naming convention the developer
used, that user could subvert the application by writing his own version
of the UI which contains an "Administrative User Flag" field (or any
other field for that matter) and the basic form processing in Struts
will kindly honor the request and set the "Administrative Flag" on the
user. Unless, of course, the developer makes special provisions to
prevent this behavior. However, its not entirely obvious to the
struts user (in my opinion) that this is even a concern. Am I
making sense here?
- jeff
RE: Potential Security Flaw in Struts MVC
I want to second Martin's opinion. Secrurity (e.g, authentication and authorization) should be outside of the application, if possible. In our company, we are using Entrust's getAccess in combination with Apache. It can easily protect resources (most likely defined by URL) after the application is developed. That being said, to protect on a more granular level (e.g., certain fields should be read only, or certain memus should not show up) still seems to be part of the application. But I do think it is the right direction. Shunhui -Original Message-From: Martin Duffy [mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 5:27 AMTo: [EMAIL PROTECTED]Subject: Re: Potential Security Flaw in Struts MVC A basic problem with most web development is that people arebuilding security into their applications. It should be handled outside of the application. You can have your application work in conjunction with an external security mechanism for more granular control but I the security mechanism should be external to the application for the most part. You could usefor example one of the authorization and access modules for apache. Then when you create your applicationyou can create specific *protected* URLs for say an admin area. Then only the person that is logged into the security mechanism with the proper *authorization* can access that URL (or one that contains that URL and parameters being passed to it in the URL). Security needs to be considered when building the applications but trying to build it into the application is a big mistake. A big reason to not build it into the app is that as your security requirements change you invariably have to make code changes to your application. By using an external mechanism you just change the rules governing the authorization and access control usually without any code changes to your app. - Original Message - From: Jeff Trent To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 6:37 PM Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User (the model representing the user) UserForm (an enrollment form for a new user) UserAction (Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the "Administrative User Flag" option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an "Administrative User Flag" field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the "Administrative Flag" on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
Re: Potential Security Flaw in Struts MVC
Jeff Trent wrote: True, the security realm validates if the request is legal. However, if the uderlying model objects are shared (User and UserForm objects in my example) for both admin and user level forms, then the request could be manipulated to set other fields beyond what was exposed for the normal user because struts takes each name, value pair in the request and calls the appropriate setter in the form for that name. Listen, it doesn't really matter. Its highly unlikely anybody can exploit this so I'm going to drop the issue. I don't want to appear to be a flame here. Actually, I just wanted to make sure that I understood what the possible security hole was. :) Now I understand what you are doing. We haven't run across this because we haven't implemented any admin screens that differ from user screens (yet). Im glad you brought the issue up, because it is something that could be overlooked. :) - jeff - Original Message - From: Peter Alfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 4:14 PM Subject: Re: Potential Security Flaw in Struts MVC Sure. You could create a jsp page that had the fields you would like, and even call off a remote action from your own page. However, if I route my actions through a security realm, then the requested action will be denied because the current user is not logged in. Or.. If the would be hacker is actualy a valid user on the system and has a username/passsword, and he trys send his own page (along with additional fields) it will still be caught by the secuirty realm. The danger would exist if either form fields, or query string parameters were being used as an action flag. If the view, update, add, delete are different actions, then the user will be required to have a valid login before the action will even be executed. Pete Jeff Trent wrote: No, I can write a form locaally and have the action run on your server... - Original Message - From: Peter Alfors [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 1:56 PM Subject: Re: Potential Security Flaw in Struts MVC Wouldn't the hacker have to get the new form class into the classpath of the server since all of the code runs server side? Jeff Trent wrote: That is not what my thinking was. But that could be an issue also. My concern is someone intentionally and maliciously creating a form to supply more parameters than originally intented by the developer. For instance, consider the UserForm fields: Name(available to enrollment administrative interface) Address(available to enrollment administrative interface) Phone(available to enrollment administrative interface) Email(available to enrollment administrative interface) ApprovedUserFlag(available to administrative interface only) AdministrativeUserFlag (available to administrative interface only) If a user knows your naming concention, they can write their own form to override the administrative-level fields above. - Original Message - From: Anthony Martin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 11:59 AM Subject: RE: Potential Security Flaw in Struts MVC Jeff, Are you asking if book marking a URL that contains query parameters might be a security risk? Anthony -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 8:37 AM To: [EMAIL PROTECTED] Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User(the model representing the user) UserForm(an enrollment form for a new user) UserAction(Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the Administrative User Flag option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is
Re: Potential Security Flaw in Struts MVC
I think I must be missing something... I don't see how a user/hacker is going to gain access to the system if one is using security. hackers arent always from the outside, you also have to protect yourself from legitimate users, who could try to force the system. Not every secure user is trust worthy user... Casey Kochmer [EMAIL PROTECTED] _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Potential Security Flaw in Struts MVC
Yes I think that's a problem; interesting that you would do it that way,
I never saw it from that perspective. But I believe the intent of Struts
(e.g. the examples, etc) is that your ActionForms are really just forms --
conduits for moving field values between HTML forms and Java primitives.
They shouldn't really involve themselves with your model at all. Keep your
model interactions in your Action perform()'s.
Other comments I've seen in this vein are with regards to validation. In
your ActionForms' validate methods, you should validate the data for basic
type-correctness (e.g. did the user really enter a date in the date field?).
But for business-model validation, save it for the Action class (e.g. did
the user enter a date not already booked?). This is sort of a two-phase validation
approach which separates basic validation logic from business model logic.
Bryan
Jeff Trent wrote:
018501c0d739$fa597bd0$6401a8c0@PROVIDENCE">
Ah, this maybe a problem in the way I've
adapted Struts. I reflect all UserForm method calls directly into the contained
User object owned by the UserForm. So for instance, I have
public class UserForm extends ActionsForm
{
protected User user;
...
public String getName()
{
return user.getName();
}
public void setName(String name)
{
user.setName(name);
}
...
}
Now can you begin to see my original concern?
Maybe I need to separate the model from the form a little more than what
I have.
- jeff
- Original Message -
From:
BryanField-Elliot
To:
[EMAIL PROTECTED]
Sent: Monday, May 07, 2001 4:38 PM
Subject: Re: Potential Security Flaw inStruts MVC
Either you are misunderstanding Struts, or I ammisunderstanding you.
Struts will populate your UserForm for you, priorto your UserAction being
called. However, it is your responsibility to, withinUserAction, copy
the values from UserForm toUser.
Bryan
Jeff Trent wrote:
00bd01c0d728$40864960$6401a8c0@PROVIDENCE" type="cite">
Bryan,
This is good advice. However, I thought
the beans are populated off of the request outside of the control of
my Action class derivation. Therefore, copyProperties() doesn't
pertain.
- jeff
-Original Message -
From:
BryanField-Elliot
To:
[EMAIL PROTECTED]
Sent:Monday, May 07, 2001 1:14 PM
Subject:Re: Potential Security Flaw in Struts MVC
There is a security risk here as you describe, if (and onlyif) you
are using a generic introspection-based function (like Struts'PropertyUtils.copyBean)
to copy the values from the UserForm object to theUser object. There
are several ways to avoid this --
1. Don't putan admin flag "setter" method in your User class.
2. In UserAction,don't use the generic bean copy utility -- instead,
manually copy thevalues, excluding the admin flag.
3. As a smarter alternative to #2,don't use a generic bean copy utility
-- instead, write an intelligentcopy function in the User class,
which "knows" that it's copying FROM aUserForm, TO a User, and therefore,
skip the copying of the Adminflag.
Bryan
Jeff Trent wrote:
002501c0d70b$9df009a0$6401a8c0@PROVIDENCE" type="cite">
I may be wrong about this (only
been working w/ Struts for a week now). But I do see a potential
security flaw in struts that I would like to hear from others
regarding.
Consider a simple set of struts
classes that represent a user in a system. You would probably have
classes that look something like this:
User
(the model representing the user)
UserForm (an
enrollment form for a new user)
UserAction
(Saves the UserForm information to db, etc)
The User class would have accessors
and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(),
setAdministrativeUserFlag(), etc. The basic implementation of the
UserForm is to take the UI form data, introspect the beans, and
call the correct modifier of the UserForm bean based on the fields
contained within the UI submission/form. A developer of course
would not expose the "Administrative User Flag" option on the UI
for enrollment (that would be found possibly in some other administrative-level
module). However, if someone is familiar with the db schema and
the naming convention the developer used, that user could subvert
the application by writing his own version of the UI which
Struts forms and JSP components/templates
I'm working on a very complex webapp with hundreds of form pages. Frequently there are chunks of a form that are shared across several pages. I was hoping to use the components library to separate these common form chunks into reusable pages, but I'm not having much luck with this. The problem is that the struts html:form tag stores data in the PageContext of the enclosing page, where individual input tags that appear in the the included components are unable to access them. I don't know if there's anything I can do about this from my application's end. Does anyone have any suggestions...hopefully something other than don't do that! ;-) Would it make any sense to change html:form to use the request context rather than the page context? TIA, -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW/ 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863
RE: Potential Security Flaw in Struts MVC
It's
fine to nest a JavaBean in an ActionForm if that bean is just a transport object
that is passed to EJBs but it probably isn't a good idea to nest your model
objects directly in the form.
If you
are going to nest a javabean in a form you don't need the getName()/setName()
methods, you can just have a getUser()/setUser() and reference the properties of
the nested bean by labeling the field in your jsp as
"user.name".
Hal
-Original Message-From: Jeff Trent
[mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 5:09
PMTo: [EMAIL PROTECTED]Subject: Re:
Potential Security Flaw in Struts MVC
Ah, this maybe a problem in the way I've adapted
Struts. I reflect all UserForm method calls directly into the contained
User object owned by the UserForm. So for instance, I have
public class UserForm extends
ActionsForm
{
protected User
user;
...
public String
getName()
{
return
user.getName();
}
public void setName(String
name)
{
user.setName(name);
}
...
}
Now can you begin to see my original
concern? Maybe I need to separate the model from the form a little more
than what I have.
- jeff
- Original Message -
From:
Bryan
Field-Elliot
To: [EMAIL PROTECTED]
Sent: Monday, May 07, 2001 4:38
PM
Subject: Re: Potential Security Flaw in
Struts MVC
Either you are misunderstanding Struts, or I am
misunderstanding you.Struts will populate your UserForm for you,
prior to your UserAction being called. However, it is your responsibility
to, within UserAction, copy the values from UserForm to
User.BryanJeff Trent wrote:
00bd01c0d728$40864960$6401a8c0@PROVIDENCE">
Bryan,
This is good advice. However, I thought
the beans are populated off of the request outside of the control of my
Action class derivation. Therefore, copyProperties() doesn't
pertain.
- jeff
-
Original Message -
From:
Bryan Field-Elliot
To:
[EMAIL PROTECTED]
Sent:
Monday, May 07, 2001 1:14 PM
Subject:
Re: Potential Security Flaw in Struts MVC
There is a security risk here as you describe, if (and
only if) you are using a generic introspection-based function (like
Struts' PropertyUtils.copyBean) to copy the values from the UserForm
object to the User object. There are several ways to avoid this
--1. Don't put an admin flag "setter" method in your User
class.2. In UserAction, don't use the generic bean copy utility --
instead, manually copy the values, excluding the admin flag.3. As a
smarter alternative to #2, don't use a generic bean copy utility --
instead, write an intelligent copy function in the User class, which
"knows" that it's copying FROM a UserForm, TO a User, and therefore,
skip the copying of the Admin flag.BryanJeff
Trent wrote:
002501c0d70b$9df009a0$6401a8c0@PROVIDENCE">
I may be wrong about this (only been
working w/ Struts for a week now). But I do see a potential
security flaw in struts that I would like to hear from others
regarding.
Consider a simple set of struts classes
that represent a user in a system. You would probably have classes
that look something like this:
User
(the model
representing the user)
UserForm (an enrollment form for
a new user)
UserAction (Saves the UserForm
information to db, etc)
The User class would have accessors and
modifiers like getFirstName(), setFirstName(),
getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc.
The basic implementation of the UserForm is to take the UI form data,
introspect the beans, and call the correct modifier of the UserForm
bean based on the fields contained within the UI
submission/form. A developer of course would not expose the
"Administrative User Flag" option on the UI for enrollment (that would
be found possibly in some other administrative-level module).
However, if someone is familiar with the db schema and the naming
convention the developer used, that user could subvert the application
by writing his own version of the UI which contains an "Administrative
User Flag" field (or any other field for that matter) and the basic
form processing in Struts will kindly honor the request and set the
"Administrative Flag" on the user. Unless, of course, the
developer makes special provisions to prevent this
RE: Potential Security Flaw in Struts MVC
Carl, I think you're right except that you also need: 3. A custom tag that uses the same security model as the Action which is only required if a .JSP is accessed directly. Personally, I pre-populate a lot of my views, so most of the time I'm hitting the Action first. Anthony -Original Message- From: George, Carl [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 1:01 PM To: '[EMAIL PROTECTED]' Subject: RE: Potential Security Flaw in Struts MVC I think you are trying to make things too hard, you could handle this relatively simple in two different ways: 1. You could inherit your actions from a super class that simple check to see if the user is logged our has sufficient privileges. And add a super(request) method as the first line of the action. 2. Have a security class that is called in the first line, maybe from an action interface, and check the login and privs that way. The security class could have a call to a session bean that holds all the security info. -Original Message- From: Jeff Trent [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 2:47 PM To: [EMAIL PROTECTED] Subject: Re: Potential Security Flaw in Struts MVC Beyond the scope of my brain container class (maybe in a week or so I'll know how to translate what you just said in terms of what I know) :^ - Original Message - From: Jason Chaffee mailto:[EMAIL PROTECTED] To: '[EMAIL PROTECTED]' mailto:'[EMAIL PROTECTED]' Sent: Monday, May 07, 2001 1:28 PM Subject: RE: Potential Security Flaw in Struts MVC You can easily guard against this by using simple JavaBeans in the presentation layer and having your action class do the persistant storage from you JavaBean view layer. -Original Message- From: Jeff Trent [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Monday, May 07, 2001 9:50 AM To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Subject: Re: Potential Security Flaw in Struts MVC That is not what my thinking was. But that could be an issue also. My concern is someone intentionally and maliciously creating a form to supply more parameters than originally intented by the developer. For instance, consider the UserForm fields: Name(available to enrollment administrative interface) Address(available to enrollment administrative interface) Phone(available to enrollment administrative interface) Email(available to enrollment administrative interface) ApprovedUserFlag(available to administrative interface only) AdministrativeUserFlag (available to administrative interface only) If a user knows your naming concention, they can write their own form to override the administrative-level fields above. - Original Message - From: Anthony Martin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 11:59 AM Subject: RE: Potential Security Flaw in Struts MVC Jeff, Are you asking if book marking a URL that contains query parameters might be a security risk? Anthony -Original Message- From: Jeff Trent [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Monday, May 07, 2001 8:37 AM To: [EMAIL PROTECTED] Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User(the model representing the user) UserForm(an enrollment form for a new user) UserAction(Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the Administrative User Flag option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an Administrative User Flag field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the Administrative Flag on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
RE: Struts forms and JSP components/templates
Title: RE: Struts forms and JSP components/templates I think the scope of the form is specified in struts-config.xml, you can put it in session scope. Shunhui -Original Message- From: Tim Moore [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 2:40 PM To: '[EMAIL PROTECTED]' Subject: Struts forms and JSP components/templates I'm working on a very complex webapp with hundreds of form pages. Frequently there are chunks of a form that are shared across several pages. I was hoping to use the components library to separate these common form chunks into reusable pages, but I'm not having much luck with this. The problem is that the struts html:form tag stores data in the PageContext of the enclosing page, where individual input tags that appear in the the included components are unable to access them. I don't know if there's anything I can do about this from my application's end. Does anyone have any suggestions...hopefully something other than don't do that! ;-) Would it make any sense to change html:form to use the request context rather than the page context? TIA, -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW/ 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863
RE: Struts forms and JSP components/templates
I think the change from page to request was alread made for html:form. Get the latest Struts from CVS. Hal -Original Message- From: Tim Moore [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 5:40 PM To: '[EMAIL PROTECTED]' Subject: Struts forms and JSP components/templates I'm working on a very complex webapp with hundreds of form pages. Frequently there are chunks of a form that are shared across several pages. I was hoping to use the components library to separate these common form chunks into reusable pages, but I'm not having much luck with this. The problem is that the struts html:form tag stores data in the PageContext of the enclosing page, where individual input tags that appear in the the included components are unable to access them. I don't know if there's anything I can do about this from my application's end. Does anyone have any suggestions...hopefully something other than don't do that! ;-) Would it make any sense to change html:form to use the request context rather than the page context? TIA, -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW/ 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863
RE: Struts forms and JSP components/templates
Title: RE: Struts forms and JSP components/templates That just specifies the scope where the form bean is stored. If you look at the doStartTag method in the FormTag.java source, it contains a few lines that look somethinglike this: pageContext.setAttribute(Constants.BEAN_KEY, bean); Those types of calls are what causes the problem. Specifically, when I try to includean html:textarea tag in my component, I get this error when I access the page: [ServletException in:/contentForm.jsp] Cannot find bean under name org.apache.struts.taglib.html.BEAN' javax.servlet.jsp.JspException: Cannot find bean under name org.apache.struts.taglib.html.BEAN at org.apache.struts.taglib.html.TextareaTag.doStartTag(TextareaTag.java:146) ... -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW/ 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863 -Original Message-From: Shunhui Zhu [mailto:[EMAIL PROTECTED]]Sent: Monday, May 07, 2001 6:15 PMTo: [EMAIL PROTECTED]Subject: RE: Struts forms and JSP components/templates I think the scope of the form is specified in struts-config.xml, you can put it in session scope. Shunhui -Original Message- From: Tim Moore [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 2:40 PM To: '[EMAIL PROTECTED]' Subject: Struts forms and JSP components/templates I'm working on a very complex webapp with hundreds of form pages. Frequently there are "chunks" of a form that are shared across several pages. I was hoping to use the components library to separate these common form chunks into reusable pages, but I'm not having much luck with this. The problem is that the struts html:form tag stores data in the PageContext of the enclosing page, where individual input tags that appear in the the included components are unable to access them. I don't know if there's anything I can do about this from my application's end. Does anyone have any suggestions...hopefully something other than "don't do that!" ;-) Would it make any sense to change html:form to use the request context rather than the page context? TIA, -- Tim Moore / Blackboard Inc. / Software Engineer 1899 L Street, NW/ 5th Floor / Washington, DC 20036 Phone 202-463-4860 ext. 258 / Fax 202-463-4863
RE: JBoss and struts
Yes. I'm developing using JBoss 2.2.1 with Tomcat 3.2.1. You can get an integrated download of these from this page: http://jboss.org/business/binary.html -Greg- -Original Message- From: Harden ZHU [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 4:53 AM To: [EMAIL PROTECTED] Subject: JBoss and struts Does JBoss work with Struts? Thanks Harden
Re: Potential Security Flaw in Struts MVC
Feel free. If you would like to document it, I'd be happy to find a place for it in the users guide. Calvin Yu wrote: I think that this potential exploit should probably be thoroughly documented, along with potential workarounds. Last thing we want is to have Struts being tagged as being unsecure.
Re: Potential Security Flaw in Struts MVC
This is open source. Anyone is welcome to jump in and join the management by submitting code. Jeff Trent wrote: Therefore, if I haven't reached my quota today, I'd like to suggest to management that there is a bean property (or something) that results in form fields being propogated accross multiple pages of my request/form and are managed using hidden variables alone. This would be an alternative to using session scope but would accomplish the same thing. Again, all comments are welcome...
Re: Potential Security Flaw in Struts MVC
Feel free to submit some code. Jeff Trent wrote: I like it! I second this request totally!
RE: Struts and DAO pattern. Expensive?
Title: RE: Struts and DAO pattern. Expensive? That opens up lots of questions I also have, I'm sure many of you have some solutions to these: (1)I went through a similar exercise, I first followed the Petstore example, to have a getConnection() method in my DAOs (well, I have BaseDAO, so at least the code is not duplicated). The good thing, as pointed out, is that the business object plus the DAO become self-contained. The bad thing is there are too many connections open. At first I thought that since I'm using connection pool, getting a connection is not too expensive. But I quickly found out there are a huge number of connections open at anytime for a not so complicated object hierarchy. So now all my save, delete methods now take a connection parameter (which is also for transaction purposes). But this leads to another problem (2) I follow the convention that all my business objects have: Foo, FooDAO, FooManager (and even FooFactory). FooManager contains the finder methods (getByID, getAll, etc.), now these also take a connection as a parameter. But I also made a decision to hold id references rather than object reference in my business objects (to avoid huge object hierarchy loading), and only lazily load a dependent object when getFooChild() is called (which has no parameter, as usual), which calls the manager classes, but now there doesn't seem to be a good place to get the connection to pass to getByID. What is a better way? anything should be done differently with or without entity EJBs? Any comments are appreciated. Thanks. Shunhui -Original Message- From: Vanderlei Silva [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 6:00 PM To: [EMAIL PROTECTED] Subject: Struts and DAO pattern. Expensive? Hi all, I'm right now having to deal with some tough design decisions concerning Data Access Objects (DAOs). I know this is really not a direct related Struts question, but I also understand that everybody in this list already faced this issue while integrating Struts in their model. I'm not using EJBs but this should really not be an issue, as the DAOs are supposed to be reusable in non-EJBs designs as well. What I have is struts dealing with controllers, and these controllers dealing with business ojects and DAOs. Let's see what I found/have: - J2EE Pet Store, in their DAO objects, for every new business method, they get a new connection from the pool and later release it. This makes the code cleaner at the controller side, but VERY repetitive at the DAO side (note that they replicate the getConnection,closeConnection, closeResultSet, etc... all over the DAOs. It's kind of amazing to see such a replication in a reference implementation. It also sounds very, very expensive to get a new connection every time. In some cases, a business method makes a call to another business method, and they are getting the connection twice for this. Imagine a call where the controller needs to talk to 3 DAOs and perform about 10 business method calls. They will get and close the connection 10 times. The connection pool, managed by the application server, will more than likely create a bottle neck in this whole thing. - in my approach, while testing, the controller is responsible for getting a new connection and forwarding it (through parameters) to the DAOs. The problems with this approach are: the DAOs are not a member of the Business objects, but work in parallel with them. Thus, the controller deals with both the business objects and the DAOs, and makes all the control, serving also as a bridge, or facade. The advantage of this approach is that basically, for every user request, you will have only one connection lookup, doesn't matter how many DAOs methods you call from different objects in order to full fill the request. I need to confess I'm lost. The PetStore approach sounds cleaner in some sence, but also sounds too repetite in other, and mostly, sounds way to expensive (or it isn't?). How do you see all this? Regards, Vanderlei _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: Potential Security Flaw in Struts MVC
Ted, I wish I had time. Now that I have three kids I can't spend any spare cycle(s) on anything but changing diapers! - Original Message - From: Ted Husted [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 7:46 PM Subject: Re: Potential Security Flaw in Struts MVC This is open source. Anyone is welcome to jump in and join the management by submitting code. Jeff Trent wrote: Therefore, if I haven't reached my quota today, I'd like to suggest to management that there is a bean property (or something) that results in form fields being propogated accross multiple pages of my request/form and are managed using hidden variables alone. This would be an alternative to using session scope but would accomplish the same thing. Again, all comments are welcome...
Re: Struts and DAO pattern. Expensive?
I need to confess I'm lost. The PetStore approach sounds cleaner in some sence, but also sounds too repetite in other, and mostly, sounds way to expensive (or it isn't?). Struts uses a connection pool. So when you do a getConnection() you're actually pulling one out from a pool of shared connection objects, so there is no real problem with generating a new connection. In my application I have manager objects will deal with data beans, and these managers have methods that all look the same (open connection, select data, build bean, close up, return). Yes it's a lot of cut and paste. I'd prefer to have used EJBs but the project size doesn't warrant such expense (time and effort, not money).
RE: Struts and VisualAge 3.5.3 with WTE
Here is a xsl and an ant build file to convert a web.xml file into the needed appname.webapp and the part.xml file to cut and past into the default_servlet_engine file This assumes that all your Action classes are in a Visual Age project called MyProject R, Nick build.xml webapp.xsl
JBOSS and Struts
Title: RE: Struts and DAO pattern. Expensive? Does anyone know how to make struts work with JBoss? Seems not working for me. Thanks Harden
Re: JBoss and struts
Any special setup for jboss? I put struts app under tomcat. And then run. Jboss gave errors. said classno found. I do put struts.jar at lib. Any hint? Thank you very much harden - Original Message - From: Greg Ritter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 7:01 PM Subject: RE: JBoss and struts Yes. I'm developing using JBoss 2.2.1 with Tomcat 3.2.1. You can get an integrated download of these from this page: http://jboss.org/business/binary.html -Greg- -Original Message- From: Harden ZHU [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 4:53 AM To: [EMAIL PROTECTED] Subject: JBoss and struts Does JBoss work with Struts? Thanks Harden
Re: JBoss and struts
I had no problems at all. I unzipped the JBoss + Tomcat download on a Windows 2000 box, started it using the batch script included in the bin directory, and then dropped each of the struts-*.war files into the deploy directory. They all deployed without problems. -Greg- On Monday, May 7, 2001, at 07:43 PM, Harden ZHU wrote: Any special setup for jboss? I put struts app under tomcat. And then run. Jboss gave errors. said classno found. I do put struts.jar at lib. Any hint? Thank you very much harden - Original Message - From: Greg Ritter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 07, 2001 7:01 PM Subject: RE: JBoss and struts Yes. I'm developing using JBoss 2.2.1 with Tomcat 3.2.1. You can get an integrated download of these from this page: http://jboss.org/business/binary.html -Greg- -Original Message- From: Harden ZHU [mailto:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 4:53 AM To: [EMAIL PROTECTED] Subject: JBoss and struts Does JBoss work with Struts? Thanks Harden
RE: Potential Security Flaw in Struts MVC
but if i use external security mechanism, will it be dynamic? i mean to say, if the admin wants to change his/her password from the application (using admin interface), how can he/she do that without restarting the server? -Original Message- From: Martin Duffy [SMTP:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 5:57 PM To: [EMAIL PROTECTED] Subject: Re: Potential Security Flaw in Struts MVC A basic problem with most web development is that people are building security into their applications. It should be handled outside of the application. You can have your application work in conjunction with an external security mechanism for more granular control but I the security mechanism should be external to the application for the most part. You could use for example one of the authorization and access modules for apache. Then when you create your application you can create specific *protected* URLs for say an admin area. Then only the person that is logged into the security mechanism with the proper *authorization* can access that URL (or one that contains that URL and parameters being passed to it in the URL). Security needs to be considered when building the applications but trying to build it into the application is a big mistake. A big reason to not build it into the app is that as your security requirements change you invariably have to make code changes to your application. By using an external mechanism you just change the rules governing the authorization and access control usually without any code changes to your app. - Original Message - From: Jeff Trent mailto:[EMAIL PROTECTED] To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sent: Monday, May 07, 2001 6:37 PM Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User(the model representing the user) UserForm(an enrollment form for a new user) UserAction(Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data, introspect the beans, and call the correct modifier of the UserForm bean based on the fields contained within the UI submission/form. A developer of course would not expose the Administrative User Flag option on the UI for enrollment (that would be found possibly in some other administrative-level module). However, if someone is familiar with the db schema and the naming convention the developer used, that user could subvert the application by writing his own version of the UI which contains an Administrative User Flag field (or any other field for that matter) and the basic form processing in Struts will kindly honor the request and set the Administrative Flag on the user. Unless, of course, the developer makes special provisions to prevent this behavior. However, its not entirely obvious to the struts user (in my opinion) that this is even a concern. Am I making sense here? - jeff
Re: Potential Security Flaw in Struts MVC
If you use something like one of the mod_ldap implementations for apache the admin would have his password in the ldap directory. I also am pretty sure that there is a auth module for apache that uses a database like MySQL. In that case the admins id and password would be in the database. So when he changes his password he does not have to restart the application. The apache modules would respect the fact that he authenticated to either the directory or the database and authorize access to the application. In either case the authorization and access control for individual URL's for the web server (and your application) would be regulated by the apache module and not by your application. In my estimation, building security mechanisms into Struts will be a slippery slope downhill. It is something that is best suited for the existing apache authorization and access modules or other external security mechanisms. I can see that it would be a good thing for creating a project to extend some of the existing apache auth and access modules to incorporate protecting servlets and EJB's. A number of them already can control authorization and access control for web servers and individual URLs. If you go to the Apache module registry and do a search on auth, ldap or I think access you will find quite a few modules that can probably suit your needs. There is one particular mod_ldap that I think is better than the others but there are quite a few to choose from and I think that many would fulfill most peoples needs. If you are using either a database or a directory you can also use them to supply user and group attributes to control the access to different functions in your application by checking the attributes for the user or group and displaying or not displaying something like a button or menu selection in the page. You could use the LDAP or DB taglibs for doing things like this in conjunction with the external security mechanism that would be protecting the access to the URLs. But the actual protection of the URLs should be external to the app. I would say look elsewhere for security for your applications and do not in build it into the Struts framework. . - Original Message - From: Manabendra Sarkar [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: 'Martin Duffy' [EMAIL PROTECTED] Sent: Tuesday, May 08, 2001 8:08 AM Subject: RE: Potential Security Flaw in Struts MVC but if i use external security mechanism, will it be dynamic? i mean to say, if the admin wants to change his/her password from the application (using admin interface), how can he/she do that without restarting the server? -Original Message- From: Martin Duffy [SMTP:[EMAIL PROTECTED]] Sent: Monday, May 07, 2001 5:57 PM To: [EMAIL PROTECTED] Subject: Re: Potential Security Flaw in Struts MVC A basic problem with most web development is that people are building security into their applications. It should be handled outside of the application. You can have your application work in conjunction with an external security mechanism for more granular control but I the security mechanism should be external to the application for the most part. You could use for example one of the authorization and access modules for apache. Then when you create your application you can create specific *protected* URLs for say an admin area. Then only the person that is logged into the security mechanism with the proper *authorization* can access that URL (or one that contains that URL and parameters being passed to it in the URL). Security needs to be considered when building the applications but trying to build it into the application is a big mistake. A big reason to not build it into the app is that as your security requirements change you invariably have to make code changes to your application. By using an external mechanism you just change the rules governing the authorization and access control usually without any code changes to your app. - Original Message - From: Jeff Trent mailto:[EMAIL PROTECTED] To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Sent: Monday, May 07, 2001 6:37 PM Subject: Potential Security Flaw in Struts MVC I may be wrong about this (only been working w/ Struts for a week now). But I do see a potential security flaw in struts that I would like to hear from others regarding. Consider a simple set of struts classes that represent a user in a system. You would probably have classes that look something like this: User(the model representing the user) UserForm(an enrollment form for a new user) UserAction(Saves the UserForm information to db, etc) The User class would have accessors and modifiers like getFirstName(), setFirstName(), getAdministrativeUserFlag(), setAdministrativeUserFlag(), etc. The basic implementation of the UserForm is to take the UI form data,
