All,
Up to this point our application has used method=POST for every form. In
general we're not too big on using GET due to the long messy URLs and people
being able to save or share requests that may or may not work the same all the
time for everyone.
For user experience reasons, we're
Stripes has a mechanism for encrypting stuff, but I don't think it'll be
too useful in your situation.
I don't think there's a need for a hardcode encryption on the client
side, what they input in the form is not reliable anyway, so what would
strong encryption give you? They already know
Why aren't those sourcePage and fp parameters encrypted?
Nevermind on that point, I have the thing set in debug mode locally...
public static String encrypt(String input) {
if (input == null)
input = ;
// encryption is disabled in debug mode
Configuration
The __fp and _sourcePage values are encrypted as of Stripes 1.5 unless you
have Stripes.DebugMode turned on in your web.xml.
You can use @Validate(encrypted=true) to have form values encrypted when
written out and automatically decrypted when read back in for binding.
As for getting rid of the
Right so the trick of a redirect and using two requests for one. That would
work but I don’t really like the two request thing. We’d probably have to
persist the key-value pair in a table somewhere or they’d be invalid after an
app restart. I do like that idea as we could store timestamps
It's not possible to bypass the two requests per one part if you want
the URL mangling done server-side. If there's only going to be a single
request, everything must be done on the client-side. So you'd have to
trust their clock when timestamping, etc. Not nice at all.
The __fp and _sourcePage values are encrypted as of Stripes 1.5 unless you
have Stripes.DebugMode turned on in your web.xml.
I did... lol
You can use @Validate(encrypted=true) to have form values encrypted when
written out and automatically decrypted when read back in for binding.
Yep, we are
Right, I'd strongly prefer one billion requests for a simple task opposed to
trusting anything from a client. In real life the two requests probably isn't
a killer.. i'll have to try it out.
-Original Message-
From: Grzegorz Krugły [mailto:g...@karko.net]
Sent: Tuesday, September
For user experience reasons, we're looking at converting the read only
forms to GET like they probably should have been in the first place
Why not using s:link for such things - It'd result in a GET by definition?
2011/9/27 Newman, John W newma...@d3onc.com
Right, I'd strongly prefer one
I think that it's going to have even less of an impact if some of those
forms are used more than once by the same user. You can do 301 permanent
http redirect so the user agent won't hit the original URL with s more
than once for the same query at least.
Also, I don't think you need Tomcat
10 matches
Mail list logo
