On 13-04-2009 at 02:34, Samuel Santos wrote:
> I use StripesSecurityFilter [2] since Stripes 1.4.2, but lately all I see
> about Stripes security is related to the SecurityInterceptor from
> Stripes-Stuff. By only looking at its page [3] it's not clear to me what the
> real advantages over the ACL
On 15-04-2009 at 10:09, Stone, Timothy wrote:
> While I do not have a solution to pass along, I have suggestion based on
> what we use here: a field annotation.
>
> @Secure for example prints on the object's toString method the last four
> digits of an SSN.
>
> Conceivably, one could have a @Pass
Ah. Well, I sympathize with the desire to avoid "ossification" of the
form-action relationship, but personally I do that by not locking in
the event name when I don't want it locked in :-)
On Wed, Apr 15, 2009 at 11:33 AM, Ben Gunter wrote:
> Maybe this will shed a little bit of light:
> http:
Maybe this will shed a little bit of light:
http://www.stripesframework.org/jira/browse/STS-258
Personally, I think it would be a useful feature.
-Ben
On Wed, Apr 15, 2009 at 12:09 PM, Mike McNally wrote:
> Currently I'm using the following approach in order to have a form
> action URL include
Currently I'm using the following approach in order to have a form
action URL include an event name for an action with "{$event}"
embedded in its url mapping:
1) Use s:url to make a URL with the appropriate event embedded
2) Use that URL in the "action" attribute of the s:form tag
3) Repeat the be
> -Original Message-
> From: Thomas Schlosser [mailto:tho...@schlosser-home.de]
> Sent: Tuesday, April 14, 2009 3:17 PM
> To: stripes-users@lists.sourceforge.net
> Subject: [Stripes-users] Password Logging as plain text
>
> Hi,
> I have found out that stripes logs the values(also value
Well logging external input (that is, stuff typed into forms) can be
exploited for evil purposes, and the logging facility really should
provide for the sanitization of user data. Password scrubbing might be
considered part of that, though really it's not just passwords that
should be scrubbed out.
Just include the information that if the log levels of your software
will debug aut passwords if the log level is set to debug in you
documentation. I have worked with many security aware linux daemons
and many of them are debugging out the passwords they retrieve(Thank
god they do this). Take free
Hello Richard,
I agree with you. But the problem is that some applications have to be
delivered to other organizations to run productive. And it is impossible
to be sure that the log level is set to INFO and not to DEBUG on this
system.
Cheers,
Thomas
Richard Hauswald schrieb:
> Hello Tomas,
>
