Cleaning up / shrinking / obfuscating query string parameters?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Cleaning up / shrinking / obfuscating query string parameters?

Newman, John W-2

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

 

 

John W. Newman

Programmer

Description: Description: Description: C:\Users\newmjw\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.Outlook\TKMGHKML\d3via_logo (2).gif

5750 Centre Avenue, Suite 500

Pittsburgh, PA 15206

Tel  412-204-0116

[hidden email]

www.d3onc.com

Fax 412-365-0749

 

This e-mail may contain confidential information of the sending organization. Any unauthorized or improper disclosure, copying, distribution, or use of the contents of this e-mail and attached document(s) is prohibited. The information contained in this e-mail and attached document(s) is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify the sender immediately by e-mail and delete the original e-mail and attached document(s).

 

 


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up / shrinking / obfuscating query string parameters?

Grzegorz Krugły
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up / shrinking / obfuscating query string parameters?

Newman, John W-2
In reply to this post by Newman, John W-2

>”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:[hidden email]]
Sent: Tuesday, September 27, 2011 11:34 AM
To: Stripes Users List ([hidden email])
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up / shrinking / obfuscating query string parameters?

Ben Gunter
In reply to this post by Newman, John W-2
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 __fp and _sourcePage parameters for a GET request, I'm not sure I've ever done this, but it might work. When you write your form into the HTML, use a regular <form> tag and inside that put a <stripes:form> with the "partial" attribute turned on. I think that would eliminate those special elements while still allowing for form repopulation, etc.

There's nothing in Stripes to help much with combining multiple request parameters into one. You're on your own there.

-Ben

On Tue, Sep 27, 2011 at 11:33 AM, Newman, John W <[hidden email]> wrote:

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

 

 

John W. Newman

Programmer

Description: Description: Description: C:\Users\newmjw\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.Outlook\TKMGHKML\d3via_logo (2).gif

5750 Centre Avenue, Suite 500

Pittsburgh, PA 15206

Tel  <a href="tel:412-204-0116" value="+14122040116" target="_blank">412-204-0116

[hidden email]

www.d3onc.com

Fax <a href="tel:412-365-0749" value="+14123650749" target="_blank">412-365-0749

 

This e-mail may contain confidential information of the sending organization. Any unauthorized or improper disclosure, copying, distribution, or use of the contents of this e-mail and attached document(s) is prohibited. The information contained in this e-mail and attached document(s) is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify the sender immediately by e-mail and delete the original e-mail and attached document(s).

 

 


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up / shrinking / obfuscating query string parameters?

Newman, John W-2
In reply to this post by Grzegorz Krugły

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:[hidden email]]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up / shrinking / obfuscating query string parameters?

Grzegorz Krugły
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.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up / shrinking / obfuscating query string parameters?

Newman, John W-2
In reply to this post by Ben Gunter

> 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 using this where applicable (hidden fields).  I’m trying to encrypt (or otherwise alter) the parameter names as well as the values, and have stripes still see them the way it normally would.

 

> use a regular <form> tag and inside that put a <stripes:form> with the "partial" attribute turned on

Hmm I will have to try that out.  I don’t think validation / repopulation will still work right, but I will try.  Either way as long as the values are encrypted I think I can probably live with it.

 

>There's nothing in Stripes to help much with combining multiple request parameters into one. You're on your own there.

Ok, good to get confirmation from you on that.  We’ll see if we can come up with anything half decent.

 

Thanks Ben.

 

 

From: Ben Gunter [mailto:[hidden email]]
Sent: Tuesday, September 27, 2011 12:33 PM
To: Stripes Users List
Subject: Re: [Stripes-users] Cleaning up / shrinking / obfuscating query string parameters?

 

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 __fp and _sourcePage parameters for a GET request, I'm not sure I've ever done this, but it might work. When you write your form into the HTML, use a regular <form> tag and inside that put a <stripes:form> with the "partial" attribute turned on. I think that would eliminate those special elements while still allowing for form repopulation, etc.

 

There's nothing in Stripes to help much with combining multiple request parameters into one. You're on your own there.

 

-Ben

On Tue, Sep 27, 2011 at 11:33 AM, Newman, John W <[hidden email]> wrote:

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

 

 

John W. Newman

Programmer

5750 Centre Avenue, Suite 500

Pittsburgh, PA 15206

Tel  <a href="tel:412-204-0116" target="_blank"> 412-204-0116

[hidden email]

www.d3onc.com

Fax <a href="tel:412-365-0749" target="_blank"> 412-365-0749

 

This e-mail may contain confidential information of the sending organization. Any unauthorized or improper disclosure, copying, distribution, or use of the contents of this e-mail and attached document(s) is prohibited. The information contained in this e-mail and attached document(s) is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify the sender immediately by e-mail and delete the original e-mail and attached document(s).

 

 


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users

 


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up / shrinking / obfuscating query string parameters?

Newman, John W-2
In reply to this post by Grzegorz Krugły
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:[hidden email]]
Sent: Tuesday, September 27, 2011 12:49 PM
To: Stripes Users List
Subject: Re: [Stripes-users] Cleaning up / shrinking / obfuscating query string parameters?

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.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up / shrinking / obfuscating query string parameters?

Richard23
> 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 <[hidden email]>
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:[hidden email]]
Sent: Tuesday, September 27, 2011 12:49 PM
To: Stripes Users List
Subject: Re: [Stripes-users] Cleaning up / shrinking / obfuscating query string parameters?

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.


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users



--
Richard Hauswald
Blog: http://tnfstacc.blogspot.com/
LinkedIn: http://www.linkedin.com/in/richardhauswald
Xing: http://www.xing.com/profile/Richard_Hauswald

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up / shrinking / obfuscating query string parameters?

Grzegorz Krugły
In reply to this post by Newman, John W-2
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 source code :-) Try something like that:

         // check for URL mapping
         String rewrittenUrl = ejb.getUrlMapping(req.getRequestURI());

         // (...)

         if (rewrittenUrl == null) {
             chain.doFilter(request, response);
         } else {
             
filterConfig.getServletContext().getRequestDispatcher(rewrittenUrl).forward(request,
response);
             return;
         }


W dniu 2011-09-27 18:54, Newman, John W pisze:

> 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:[hidden email]]
> Sent: Tuesday, September 27, 2011 12:49 PM
> To: Stripes Users List
> Subject: Re: [Stripes-users] Cleaning up / shrinking / obfuscating query string parameters?
>
> 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.
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users
Reply | Threaded
Open this post in threaded view
|

Re: Cleaning up / shrinking / obfuscating query string parameters?

Newman, John W-2
Just to follow up on this, thanks for all the good responses.

The solution Grzegorz outlined is probably the best way to do it.  Originally send a post, servlet filter does rewrite service, 301 redirect to short url, filter comes back in, detects short url and does internal forward to original request.  (I hadn't thought of forward of course, good call there).

But it turns out I really don't have to do any of this.  A very very long time ago during our first beta, we had an issue where IE 6 was caching ajax responses we obviously did not want it to.  I looked at the @HttpCache piece stripes offered, but for some reason I made the poor decision to trivialize the cache response headers...  We're broken in that every forward is getting these headers added:

        protected ForwardResolution forward(String pageKey)  {
                HttpServletResponse response = getCtx().getResponse();
                response.setHeader("Cache-Control", "no-store, no-cache, must-revalidate");
                response.addHeader("Cache-Control", "post-check=0, pre-check=0");
                response.setHeader("Expires", "Fri, 01 Jan 1990 00:00:00 GMT");
                response.setHeader("Pragma", "no-cache");
                return new ForwardResolution(lookupPage(pageKey));
        }

Obviously that is not right for every type of response.  I completely forgot that piece was hiding in there since it hasn't been touched for over 3 years.  So in reading about proper use of HTTP caching headers, it is really non trivial.  I have to go through every forward and classify case by case how the caching should work.  I'm envisioning 3 or 4 different sets of response headers depending on how the response should or should not be cached.  It's really the burden of the application developer to make sure caching is handled correctly, no framework or anything is going to do this for you automatically and get it right.  Anyone sending an http response may want to read http://www.mnot.net/cache_docs 

 If I just remove the expires header on this one post, when the user goes back the page shows up right away.. this is the expected normal experience.  So I was really dead wrong with what I said about IE - it's actually a good feature on their part to alert that the page has expired.  I think the version of FF I was using did not say anything about page is expired, and just said "do you want to resend the post?".   So once again, our users are unfortunately right that it is a bug on my end.  =)
 
Thanks again.
-John

-----Original Message-----
From: Grzegorz Krugły [mailto:[hidden email]]
Sent: Tuesday, September 27, 2011 13:01
To: Stripes Users List
Subject: Re: [Stripes-users] Cleaning up / shrinking / obfuscating query string parameters?

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 source code :-) Try something like that:

         // check for URL mapping
         String rewrittenUrl = ejb.getUrlMapping(req.getRequestURI());

         // (...)

         if (rewrittenUrl == null) {
             chain.doFilter(request, response);
         } else {
             
filterConfig.getServletContext().getRequestDispatcher(rewrittenUrl).forward(request,
response);
             return;
         }


W dniu 2011-09-27 18:54, Newman, John W pisze:

> 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:[hidden email]]
> Sent: Tuesday, September 27, 2011 12:49 PM
> To: Stripes Users List
> Subject: Re: [Stripes-users] Cleaning up / shrinking / obfuscating query string parameters?
>
> 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.
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
> ------------------------------------------------------------------------------
> 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/stripes-users