>"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 configuration = StripesFilter.getConfiguration();
if (configuration != null && configuration.isDebugMode())
return input;
.....
public class Configuration extends RuntimeConfiguration {
@Override
protected Boolean initDebugMode() {
return
"dev".equals(appProperties.getString("environment"));
}
so in real life I have
_sourcePage=I4HN0m5UPlwLkwNJZW2E9IQpyv6197QwgNwVAooFT2w1ry-oUVtWpQ==
__fp=zf_qQeORoi95oKdh9cUYlC8ExapErZ6TbTAzHXTSpRt5oKdh9cUYlIj8UUTtG8E006PeHlxld74=
which i guess is ok in the url (a lot better than showing "WEB-INF"). Ideally
I'd remove those two entirely but I think they're needed for validation to work
right.
From: Newman, John W [mailto:newma...@d3onc.com]
Sent: Tuesday, September 27, 2011 11:34 AM
To: Stripes Users List (stripes-users@lists.sourceforge.net)
Subject: [Stripes-users] Cleaning up / shrinking / obfuscating query string
parameters?
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 looking at converting the "read only" forms
to GET like they probably should have been in the first place. When you go
back to a POST, firefox does a nice job of just giving you a simple confirm
message box. Click yes and you're back at the results of the post. But
reasons I don't understand, IE8 went crazy and re-did this: Send post, click
back, get a white "page is expired" page (looks like an error), click refresh,
get a message box, click retry, finally back at your results. It's a lot of
reading, mouse movement, and clicks just to go back and repost. The average
user gets lost and confused throughout this sequence and sees it as a bug on
our end.
If I just change the method to GET it works fine, but the URL is extremely
long. It has the fp and sourcePage parameters in there which shows things like
WEB-INF and other things I'd rather not have that visible. Why aren't those
sourcePage and fp parameters encrypted?
That aside, in order to switch this to get I'd like to do a couple things if I
can:
1). Rewrite the query string from ?a=1234&b=2345=c=3456 to something like
?q=6vhHABS59OP0ILkMJsL7yY5t== . ... and the stripes side should still see the
parameters as "a & b & c", as it did before, no perceivable change from its
perspective
2). Add a some tokens into the GET to keep track of when it was submitted and
by whom so we can potentially block out old or unexpected requests.
#2 is not a big deal, we can do that fairly easily through a subclass of the
form tag and an interceptor. #1 however, I'm not really sure how to go about
it. I'm not 100% but I don't think the /clean/urls/feature can solve this as
the form is kind of dynamic and has anywhere from 1-15 fields in the query. It
wouldn't translate to a restful URL. Does stripes offer anything 'out of the
box' that I can take advantage of? I feel like I am missing something.
So far the best I can come up with is to put a servlet filter before the
stripes filter that takes the "q" parameter, decodes it, and rewrites the
getParameter() pieces to look into here instead. Unfortunately this requires
using HttpServletRequestWrapper, and due to no multiple inheritance, I have to
literally copy a few pieces out of the servlet implementation we are currently*
using. So obviously that is a poor solution and I'm not going to do that.
Also, I'm not really sure how to encrypt the parameter on the client side. I
can hook into the form.submit() piece using jquery, but any encryption I put in
there is client visible and can be broken. Might I be able to hook into the
form tag or something, or is just pointless base64 encoding the best I can do
here?
Thanks for any input.
-John
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
