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 and user
accounts along with the pairs. I’ll try that out here and see how it works,
but I think the “copy pieces from tomcat svn” hack would still be required to
get the parameter customization right...
@Override
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException, ServletException {
ServletRequest result = request;
HttpServletRequest cast = (HttpServletRequest) request;
String method = cast.getMethod();
if (method != null && "GET".equals(method.toUpperCase())) {
String queryString = cast.getQueryString();
if (queryString != null && !"".equals(queryString)) {
if (isShortForm(queryString)) {
result = shortenAndMakeRedirect(cast);
// shorten and send client redirect .. client will
make second request..
} else {
result = new WrappedRequest(cast);
// wrapped request would take care of the lookup
piece. You’ll need to adjust the
// getParameter() pieces to have this custom logic, but you’ll still run
into the problem of
// having to borrow quite a bit from your particular servlet implementation.
// In my case the class I need to extend is package scoped...
}
}
}
chain.doFilter(result, response);
}
From: gshegosh [mailto:g...@karko.net]
Sent: Tuesday, September 27, 2011 12:04 PM
To: Stripes Users List
Subject: Re: [Stripes-users] Cleaning up / shrinking / obfuscating query string
parameters?
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 what they've entered.
What I'd do (actually, I'm planning to modify my little stripes-based framework
in such a way) is for the system to work a bit like a URL shortening service.
That is, I'd implement a filter that would be placed before Stripes filter in
the chain (I call it UrlRewritingFilter) and would basically tell it to do two
things:
1. If current URL looks like a GET request from a form (contains ? and & or
some better detection logic), encode it and send user a redirect to encoded URL.
2. If current URL is encoded, decode it.
By encoding I mean having a lookup Map<String,String> where keys are random,
say 7-character strings (such as r8YhrR4 - 7 [A-Za-z0-9] digits give you a
space of 62^7=3 521 614 606 208 unique keys) and values are my long, original
URLs. When encoding a URL, I'll first look it up (reverse map as a cache could
be useful for performance) and if it already exists, just return its key. If it
doesn't, just make a random new key, make sure it doesn't already exist and put
new entry.
That way URLs will be ultra short, will not be at all possible to decode
without access to the lookup table and if users copy and paste them, they'll
probably still work.
HTH,
Grzegorz
------------------------------------------------------------------------------
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
