Suppressing INFO messages

2004-10-19 Thread Todd Bryant
I just upgraded a struts 1.0.2 project to a 1.1 project. Everything went
fine except that I notice I have a lot of INFO messages in the console,
e.g., 

I org.apache.struts.util.PropertyMessageResources  Initializing,
config='org.apache.struts.taglib.html.LocalStrings', returnNull=true

I do not want these info messages in stdout. I understand that struts now
uses commons-logging, which from what I understand uses either log4j,
java1.4, or SimpleLog to log output. I have tried putting in a
log4j.properties and a simpelog.properties file and it has not suppressed
the output. At this point I cannot tell which logging API I am using. 

I am having a terrible time trying to find information about this using
google or the mail list archive. Is there an easy solution? Thank you very
much for any input you can give me. 

Todd Bryant
Programmer/Analyst
University of Nebraska Foundation
402-472-0107



NOTE:  This electronic message and attachment(s), if any, contains
information which is intended solely for the designated recipient(s).
Unauthorized disclosure, copying, distribution, or other use of the contents
of this message or attachment(s), in whole or in part, is prohibited without
the express authorization of the sender of this message. 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Suppressing INFO messages

2004-10-19 Thread Todd Bryant
 Thanks Eddie. I actually did make a properties file like that one and had
it in my default package in the WEB-INF/classes dir, but it did not change.
I also noted in the documentation that SimpleLog outputs to stderr, which
mine is not, so it must not be using SimpleLog. 

I was confused at first what logging it was using (because I noticed class
files in the commons-logging jar for log4j, but have since realized these
are wrapper classes IN CASE you are using log4j, which I am not). Since
SimpleLog seems to output to stderr, that means I must be using jvm 1.4
logging, which is entirely possible since I am using 1.4 for development.

I tried to change the logging.properties file for my runtime, but I cannot
be sure which runtime is being used in my environment. The ones I changed
did nothing. I am using IBM WSAD (based on Eclipse) for dev. 

What I would prefer is to change the logging so it forces the use of
SimpleLog and then make simplelog only output errors like you suggested(this
is because my production evironment currently uses jvm 1.3 and this would
make it consistent). I tried following the directions outlined at this link,
but had no luck. 

http://www.oracle.com/technology/products/jdev/tips/mills/Struts-logging.htm
l 

Any further suggestions? Thanks for your help. 



-Original Message-
From: Eddie Bush
To: Struts Users Mailing List
Sent: 10/19/2004 7:13 PM
Subject: Re: Suppressing INFO messages

My apologies.  You should have created that file in the default package.
I 
neglected to mention that and didn't even notice til just now.

- Original Message - 
From: Eddie Bush [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Sent: Tuesday, October 19, 2004 7:05 PM
Subject: Re: Suppressing INFO messages


 If there's a Log4J JAR in the classpath, you should be using Log4J.
If 
 not, you're likely using the SimpleLog implementation.

 You said you tried putting a ... and a simplelog.properties file but

 that it didn't suppress the output.  Where did you put this file and
what 
 did you put inside of it?

 You *should* have created a file called simplelog.properties and put
in 
 the following line:
 org.apache.commons.logging.simplelog.defaultlog=error

 That should only show logging lines of level error or higher.

 - Original Message - 
 From: Todd Bryant [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Tuesday, October 19, 2004 3:18 PM
 Subject: Suppressing INFO messages


I just upgraded a struts 1.0.2 project to a 1.1 project. Everything
went
 fine except that I notice I have a lot of INFO messages in the
console,
 e.g.,

 I org.apache.struts.util.PropertyMessageResources  Initializing,
 config='org.apache.struts.taglib.html.LocalStrings', returnNull=true

 I do not want these info messages in stdout. I understand that struts
now
 uses commons-logging, which from what I understand uses either log4j,
 java1.4, or SimpleLog to log output. I have tried putting in a
 log4j.properties and a simpelog.properties file and it has not
suppressed
 the output. At this point I cannot tell which logging API I am using.

 I am having a terrible time trying to find information about this
using
 google or the mail list archive. Is there an easy solution? Thank you

 very
 much for any input you can give me.

 Todd Bryant
 Programmer/Analyst
 University of Nebraska Foundation
 402-472-0107



 NOTE:  This electronic message and attachment(s), if any, contains
 information which is intended solely for the designated recipient(s).
 Unauthorized disclosure, copying, distribution, or other use of the 
 contents
 of this message or attachment(s), in whole or in part, is prohibited 
 without
 the express authorization of the sender of this message.


 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




 ---
 avast! Antivirus: Outbound message clean.
 Virus Database (VPS): 0443-0, 10/19/2004
 Tested on: 10/19/2004 7:05:33 PM
 avast! - copyright (c) 2000-2004 ALWIL Software.
 http://www.avast.com




 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

 



---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0443-0, 10/19/2004
Tested on: 10/19/2004 7:13:50 PM
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


NOTE:  This electronic message and attachment(s), if any, contains
information which is intended solely for the designated recipient(s).
Unauthorized disclosure, copying, distribution, or other use of the contents
of this message or attachment(s), in whole or in part, is prohibited without
the express authorization of the sender of this message

RE: Problem with Formbean validate method forwarding to input pag e

2004-04-08 Thread Todd Bryant
Excellent idea Ray. I just need to set the validate param in the web.xml for
the action servlet to false. Then I am good. 

Thanks Ray, sometimes you just can't see the simple solutions when they are
right in front of you.
 

-Original Message-
From: Ray Madigan [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 07, 2004 5:39 PM
To: Struts Users Mailing List; [EMAIL PROTECTED]
Subject: RE: Problem with Formbean validate method forwarding to input pag e

Why don't you tell your action not to validate, and call validate yourself
in your action.  Seems like you will have all of the control you need.

-Original Message-
From: Paul Barry [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 07, 2004 3:18 PM
To: Struts Users Mailing List
Subject: Re: Problem with Formbean validate method forwarding to input
pag e


The form bean is populated by the RequestProcessor, but you can put your
logic to validate the session where ever you want.  The easiest way to
understand it is to just look at the source code for
org.apache.struts.action.RequestProcessor.  It has a number of
processXXX methods, one being processPreprocess.  You might want to put
your session validation there, which does it before the bean is
instatiated, populated and validated and before processActionPerform is
called.



Todd Bryant wrote:

 Interesting. I have never looked at the request processor before. The main
 question I have is - is the formbean populated BEFORE the request
processor
 runs or after? If the form bean is populated before the method you
mention,
 then the request process will still be circumvented by the formbean.

 -Original Message-
 From: Paul Barry [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, April 07, 2004 4:47 PM
 To: Struts Users Mailing List
 Subject: Re: Problem with Formbean validate method forwarding to input
page

 Maybe you should be handling your security in the request processor.
 Have a method like this:

 protected ActionForward processActionPerform(
  HttpServletRequest request,
  HttpServletResponse response,
  Action action,
  ActionForm form,
  ActionMapping mapping)
  throws IOException, ServletException {
  try {
  validSession(request);
  return (action.execute(mapping, form, request, response));
  } catch (SecurityException e) {
  return (processException(request, response,e, form, mapping));
  }
 }

 Where validateSession throws a SecurityException if the user is not
 logged in and processException knows where to send the user to log in.
 There are different ways to do it, but the basic principle is to
 authenticate the user's session before the Action executes, so you don't
 have to worry about that in the Action.

 Todd Bryant wrote:


That is a good suggestion, and I had thought of that, but the problem is
that a user would have to go from the error page back to the page they

 were

on. This would make it prohibitively difficult to interact with this
particular app (too many clicks).

-Original Message-
From: Paul Barry [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 07, 2004 4:07 PM
To: Struts Users Mailing List
Subject: Re: Problem with Formbean validate method forwarding to input

 page

Make your input action an error page, which just has the error and no
sensitive data and make a success forward that you only send the user to
if everything checks out.

Todd Bryant wrote:



I have need for every page in my web app to be secure. What I originally

did


was extend the Action class to make a secure action class. The
SecureAction's perform method validates that the user is logged in and if
not, sends them to the login page. All actions in my app extend
SecureAction. To protect my jsp's, I put them in a subfolder of WEB-INF,
WEB-INF/jsp. This way a user cannot directly access any jsp. They can
only
be accessed through a forward in an action. This completely secures all
resources in my application.



This is where I run into a problem. If I use the validate() method of the
formbean and it returns a non-empty ActionErrors object, then the request

is


diverted to resource that is set as the input, in this case a jsp.

Because


of this, if a user were to put in some bogus field values in the url, she
would be able to cause the formbean to no validate and get the jsp to
display, bypassing the secure action. I can secure each jsp, but this is
redundant if I have them in the WEB-INF folder in the first place. I
would
rather avoid this fix.



I know that overriding the default action class is a common way to secure
your app as I have read about it more than one place, however, I have

never


seen this problem addressed. Has anyone else ran across this problem

before


and come up with a solution? Thanks in advance.



Todd Bryant

Programmer/Analyst

University of Nebraska Foundation

402-472-0107








-
To unsubscribe

Problem with Formbean validate method forwarding to input page

2004-04-07 Thread Todd Bryant
I have need for every page in my web app to be secure. What I originally did
was extend the Action class to make a secure action class. The
SecureAction's perform method validates that the user is logged in and if
not, sends them to the login page. All actions in my app extend
SecureAction. To protect my jsp's, I put them in a subfolder of WEB-INF,
WEB-INF/jsp. This way a user cannot directly access any jsp. They can only
be accessed through a forward in an action. This completely secures all
resources in my application. 

 

This is where I run into a problem. If I use the validate() method of the
formbean and it returns a non-empty ActionErrors object, then the request is
diverted to resource that is set as the input, in this case a jsp. Because
of this, if a user were to put in some bogus field values in the url, she
would be able to cause the formbean to no validate and get the jsp to
display, bypassing the secure action. I can secure each jsp, but this is
redundant if I have them in the WEB-INF folder in the first place. I would
rather avoid this fix. 

 

I know that overriding the default action class is a common way to secure
your app as I have read about it more than one place, however, I have never
seen this problem addressed. Has anyone else ran across this problem before
and come up with a solution? Thanks in advance. 

 

Todd Bryant

Programmer/Analyst

University of Nebraska Foundation

402-472-0107

 

 



RE: Problem with Formbean validate method forwarding to input pag e

2004-04-07 Thread Todd Bryant
That is a good question. The problem is the way struts processes requests.
The first thing struts does when receiving a request to an action is to fill
in the formbean associated with the action. Then it runs the validate()
method of the formbean. If the method returns a non-empty ActionErrors
object, the request is forwarded to whatever is set as the input in the
struts config. If I set the input to the action, it will request that
action again, causing an infinite loop (requests to actions fill in the form
bean first, validate runs, send back to action, repeat). 


Thinking just now, I would have to have an action for every jsp in my
application (A forwarding action if you will). This action would do nothing
but authenticate a user and then forward to the jsp. Then the jsp would
submit to a 'business' action that forwards back to the same jsp again (this
jsp has a form for user data AND displays info). I could set the input of
the formbean to the forwarding action. This would auth a user, but would not
cause a loop because the formbean would only be associated with the
business bean.

This plan sounds doable. I hope I made sense to anyone reading. If someone
else has any suggestions I would appreciate them. 



-Original Message-
From: Tin Pham [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 07, 2004 3:38 PM
To: [EMAIL PROTECTED]
Subject: Re: Problem with Formbean validate method forwarding to input page

If you are using struts, why go back to a .jsp page? You should be going
back to a .do page.

Since the .do is a struts action it will be able to get to your jsp page.


Todd Bryant [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
du...
 I have need for every page in my web app to be secure. What I originally
did
 was extend the Action class to make a secure action class. The
 SecureAction's perform method validates that the user is logged in and if
 not, sends them to the login page. All actions in my app extend
 SecureAction. To protect my jsp's, I put them in a subfolder of WEB-INF,
 WEB-INF/jsp. This way a user cannot directly access any jsp. They can only
 be accessed through a forward in an action. This completely secures all
 resources in my application.



 This is where I run into a problem. If I use the validate() method of the
 formbean and it returns a non-empty ActionErrors object, then the request
is
 diverted to resource that is set as the input, in this case a jsp.
Because
 of this, if a user were to put in some bogus field values in the url, she
 would be able to cause the formbean to no validate and get the jsp to
 display, bypassing the secure action. I can secure each jsp, but this is
 redundant if I have them in the WEB-INF folder in the first place. I would
 rather avoid this fix.



 I know that overriding the default action class is a common way to secure
 your app as I have read about it more than one place, however, I have
never
 seen this problem addressed. Has anyone else ran across this problem
before
 and come up with a solution? Thanks in advance.



 Todd Bryant

 Programmer/Analyst

 University of Nebraska Foundation

 402-472-0107










-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Problem with Formbean validate method forwarding to input pag e

2004-04-07 Thread Todd Bryant
That is a good suggestion, and I had thought of that, but the problem is
that a user would have to go from the error page back to the page they were
on. This would make it prohibitively difficult to interact with this
particular app (too many clicks). 

-Original Message-
From: Paul Barry [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 07, 2004 4:07 PM
To: Struts Users Mailing List
Subject: Re: Problem with Formbean validate method forwarding to input page

Make your input action an error page, which just has the error and no 
sensitive data and make a success forward that you only send the user to 
if everything checks out.

Todd Bryant wrote:

 I have need for every page in my web app to be secure. What I originally
did
 was extend the Action class to make a secure action class. The
 SecureAction's perform method validates that the user is logged in and if
 not, sends them to the login page. All actions in my app extend
 SecureAction. To protect my jsp's, I put them in a subfolder of WEB-INF,
 WEB-INF/jsp. This way a user cannot directly access any jsp. They can only
 be accessed through a forward in an action. This completely secures all
 resources in my application. 
 
  
 
 This is where I run into a problem. If I use the validate() method of the
 formbean and it returns a non-empty ActionErrors object, then the request
is
 diverted to resource that is set as the input, in this case a jsp.
Because
 of this, if a user were to put in some bogus field values in the url, she
 would be able to cause the formbean to no validate and get the jsp to
 display, bypassing the secure action. I can secure each jsp, but this is
 redundant if I have them in the WEB-INF folder in the first place. I would
 rather avoid this fix. 
 
  
 
 I know that overriding the default action class is a common way to secure
 your app as I have read about it more than one place, however, I have
never
 seen this problem addressed. Has anyone else ran across this problem
before
 and come up with a solution? Thanks in advance. 
 
  
 
 Todd Bryant
 
 Programmer/Analyst
 
 University of Nebraska Foundation
 
 402-472-0107
 
  
 
  
 
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Problem with Formbean validate method forwarding to input pag e

2004-04-07 Thread Todd Bryant
Interesting. I have never looked at the request processor before. The main
question I have is - is the formbean populated BEFORE the request processor
runs or after? If the form bean is populated before the method you mention,
then the request process will still be circumvented by the formbean. 

-Original Message-
From: Paul Barry [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 07, 2004 4:47 PM
To: Struts Users Mailing List
Subject: Re: Problem with Formbean validate method forwarding to input page

Maybe you should be handling your security in the request processor. 
Have a method like this:

protected ActionForward processActionPerform(
 HttpServletRequest request,
 HttpServletResponse response,
 Action action,
 ActionForm form,
 ActionMapping mapping)
 throws IOException, ServletException {
 try {
 validSession(request);
 return (action.execute(mapping, form, request, response));
 } catch (SecurityException e) {
 return (processException(request, response,e, form, mapping));
 }
}

Where validateSession throws a SecurityException if the user is not 
logged in and processException knows where to send the user to log in. 
There are different ways to do it, but the basic principle is to 
authenticate the user's session before the Action executes, so you don't 
have to worry about that in the Action.

Todd Bryant wrote:

 That is a good suggestion, and I had thought of that, but the problem is
 that a user would have to go from the error page back to the page they
were
 on. This would make it prohibitively difficult to interact with this
 particular app (too many clicks). 
 
 -Original Message-
 From: Paul Barry [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 07, 2004 4:07 PM
 To: Struts Users Mailing List
 Subject: Re: Problem with Formbean validate method forwarding to input
page
 
 Make your input action an error page, which just has the error and no 
 sensitive data and make a success forward that you only send the user to 
 if everything checks out.
 
 Todd Bryant wrote:
 
 
I have need for every page in my web app to be secure. What I originally
 
 did
 
was extend the Action class to make a secure action class. The
SecureAction's perform method validates that the user is logged in and if
not, sends them to the login page. All actions in my app extend
SecureAction. To protect my jsp's, I put them in a subfolder of WEB-INF,
WEB-INF/jsp. This way a user cannot directly access any jsp. They can only
be accessed through a forward in an action. This completely secures all
resources in my application. 

 

This is where I run into a problem. If I use the validate() method of the
formbean and it returns a non-empty ActionErrors object, then the request
 
 is
 
diverted to resource that is set as the input, in this case a jsp.
 
 Because
 
of this, if a user were to put in some bogus field values in the url, she
would be able to cause the formbean to no validate and get the jsp to
display, bypassing the secure action. I can secure each jsp, but this is
redundant if I have them in the WEB-INF folder in the first place. I would
rather avoid this fix. 

 

I know that overriding the default action class is a common way to secure
your app as I have read about it more than one place, however, I have
 
 never
 
seen this problem addressed. Has anyone else ran across this problem
 
 before
 
and come up with a solution? Thanks in advance. 

 

Todd Bryant

Programmer/Analyst

University of Nebraska Foundation

402-472-0107

 

 


 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]