I am planning a URL rewriter/encoder (maybe rewriter is a better term). The main purpose is to hide the exact URL from the client, since if he is smart enough, he can figure out how to mess up the application.
The URL encoder would be an injective function f(x) = y. The decoder would be the inverse function of f, say g such that g(y) = x. This way I can encode and decode my URLs.
A URL like:
http://www.myapp.com/servlet/myapp/template/MyScreen.vm/action/MyAction
would be encoded to something like:
http://www.myapp.com/uyatsd6787asv6dyuasgbdxuasydgb876876v
It does not matter what is in the encoded URL as far as it is not understandable.
The problem is that I do not know how to manipulate the URL that the browser displays. I am using JBoss as a servlet container and Turbine servlet as the web application framework.
I would need a module that receives the encoded URL, decodes it, passes it to Turbine, then it modifies the response's URL to show the encoded URL again.
Previous attempts to solve the problem:
I have created a servlet filter, but I can not access the URL since the filter receives a ServletRequest that is a JBoss implementation. As far as I have read it seems that a servlet filter is not a good choice for manipulating the URL.
Maybe you could do something like write a servlet that accepts the initial request, decodes the URL, and then internally forwards to your existing servlet.
For example, have a servlet that will accept:
www.myapp.com/enc/uyatsd6787asv6dyuasgbdxuasydgb876876v
This servlet could be set to handle requests that begin with /enc/ or some other marker to indicate that the URL needs to go to the decoder servlet. It would decode to the URL to:
/servlet/myapp/template/MyScreen.vm/action/MyAction
and then internally forward to this URL on your existing servlet using something like:
getServletContext().getRequestDispatcher(decoded_url).forward(req, res);
Related
I have created a GET/POST API using Spring boot which has a http url parameter say refid. Now this parameter is already encoded before invoking GET/POST request
e.g. http://localhost:8080/users/TESTFNkJXiQAH%2FJBKxigBx
But, when I deploy this through Spring Boot, the encoded refid is encoded again and the refid changes. i.e. it becomes:
http://localhost:8080/users/TESTFNkJXiQAH%252FJBKxigBx
I want to suppress this 2nd encoding by Spring boot. Can anyone advise here?
Don't know if you are still having this problem or you found out why it's happening, but because I was trying to explain to someone the phenomenon, I looked if there is already a good explanation. But since you also ask and I didn't find any, here is my answer.
So you encode your refid
TESTFNkJXiQAH%2FJBKxigBx
before you send it through the url, which then you give into a browser. Now this is only the encoded refid. When you call it through a URL directly you have to encode it again, according to the HTML URL encoding standards. That’s why the double escape. Also read this. E.g. so if your refid looks like this
test%123
and you encode it you turn it into
test%25123
now if you also want to pass it through a url on the browser you'd have to encode it again.
test%2525123
But if a service A is using this service and service A encodes this refid properly then you wont have this problem. It's happening only because you are trying to call this api endpoint through the browser.
Of course I take for granted that you are doing this:
String decoded = URLDecoder.decode(refid, "UTF-8");
in your controller
Pass the decoded URL in first place instead of doing inconvenient things to stop double encoding.
You get already decoded field in rest controller.
Example if you pass www.xyz.com?name=nilesh%20salpe
you will get value of param name as "nilesh salpe" and not "nilesh%20salpe"
This is a basic example of URLDecoder:
#RequestMapping(value = "/users/{refId}", method = GET)
public void yourMethod(#PathVariable("refId") String refId) {
// This is what you get in Spring Boot
String encoded = refId; //"TESTFNkJXiQAH%252FJBKxigBx"
String decoded = URLDecoder.decode(encoded, "UTF-8");
System.out.println(decoded);
// Result TESTFNkJXiQAH%2FJBKxigBx
}
I have been wondering if its possible to anonymize public URL. When user makes a request with this anonymized public URL, let Nginx decode, fetch and serve the URL.
Example
Public URL http://amazon.server.com/location/file.html
Anonymized URL https://amazon.server.com/09872340-932872389-390643289/983724.html
Nginx decodes 09872340-932872389-390643289/983724.html to location/file.html
Added image below for further clarification. Nginx has a reverse logic to decode, whereas Remote Server has the logic to Anonymize URL.
Question
All I need to know is how would Nginx decode anonymized URL? Nginx got anonymized URL request. There has to be a way to decode it.
This is an answer to the updated question:
Question All I need to know is how would Nginx decode anonymized URL? Nginx got anonymized URL request. There has to be a way to decode it.
Nginx would make a request to a script, e.g., either through proxy_pass or fastcgi_pass et al.
The script could decode the URL and provide the actual URL through a Location HTTP Response Header with a 302 Found HTTP Status.
Nginx would then have the decoded URL stored in the $upstream_http_location variable. It could subsequently be used in another proxy_pass et al within a named location #named, to which you could redirect the processing of the original request from the user through error_page 302 = #named.
In all, each user request would be processed twice within nginx, but it'll all be transparent to the user -- they simply receive the resource through the original URL, with all redirects being done internally within nginx.
Define Anonymize for a URL? You can use any of the same methods as URL shortners such as http://bitly.com. But that is not truely anonymous since there is a definite mapping between the shortened URL and the target public url. If you make this per user based there is still a mapping but it is user based.
Looks like what you are suggesting is a variation on the above scheme where instead of sending the user to the target URL via a redirect you want the your server to actually fetch the content and return to the user. You need to be aware of the linked content in the public URL such as style sheets and images and adjust them accordingly. Many of the standard proxies has this kind of functionality built in. Also take a look at
https://github.com/jenssegers/php-proxy
http://search.cpan.org/~book/HTTP-Proxy-0.304/lib/HTTP/Proxy.pm.
If you are planning to build your own these can serve as a base.
I think what you want to do here is somewhat similar to another question I've answered in the past, where for each request by the client, you effectively want to make two requests to two different upstreams under the hood (first one to an upstream capable of decoding the URL, second one to actually fetch said decoded URL), but, of course, only return one result.
https://serverfault.com/questions/202011/nginx-and-2-upstreams/485044#485044
As mentioned on serverfault, you could use error_page to process another request, after the first one is complete. You could then use $upstream_http_ to make the subsequent request based on the original one, for example, using $upstream_http_location.
You might also want to look into X-Accel-Redirect header, introduced in this context at proxy_ignore_headers.
I'm trying to figure out what really happens when html submit form button is clicked.
I suppose it generates some kind of http request (similar to ajax get or post call) which has data in http body and is sent to address specified in action field.
1) Am I right?
2) I've seen many ways of processing forms with PHP or ASP on server side. Can I process it with Java REST Application using e.g. Jersey? Is submit form capable of hitting REST if I put right URL in action field?
Thank You.
By submitting the form in HTML you basically tell the browser to generate a normal HTTP request, usually POST or GET, for an URL defined in tag with form fields attached according to the specified method either appended to the URL or included in the request data.
There is nothing really special or different from a "normal" HTTP request, in fact you can manually "submit a form" by appending form keys and values to the URL in your browser and navigating to it in case of GET method.
Summarizing:
1) Yes, you are right.
2) From what I've just read (never used REST personally) a REST application is implemented by a servlet mechanism and uses HTTP protocol, so it should be possible to write a REST application for processing HTML forms if the form points to this application's URL.
I have a developed a Restlet application. I would like to return a JSP file on a URL request through Restlet. How can I achieve this without using a redirect?
i.e.
Let's say I have the file "contact.jsp" on mydomain.com and I want people to be able to access contact.jsp at http://mydomain.com/contact
Thus, in Restlet, I would have:
router.attach("/contact", MyResource.class);
But how can I return the "contact.jsp" page? I know that a redirect would work, but I don't want users to see the ".jsp" in "http://mydomain.com/contact.jsp"... or is there another strategy that would work without even using restlet? Maybe some modification of my web.xml file?
Edit (2009-08-14):
My answer posted below doesn't work on App-Engine and Restlet. It does work however, if I don't include Restlet, or allow Restlet to have a url-pattern of "/*"
What would be ideal is to have a subclass of the Router that allows me to do this:
router.attach("/contact", "/contact.jsp");
Thanks!
Edit (2009-08-17):
I'm surprised I haven't had any responses since I posted a bounty. Will someone comment and let me know if my question/problem isn't clear?
Edit (2009-08-17):
Interesting observation. When using the method described by "Rich Seller" below, it works when deployed on Google App-Engine and not locally. Additionally, If I call http://mydomain.com/contact.jsp on Google App-Engine it bypasses Restlet and goes straight to the JSP. But, locally, Restlet takes over. That is, http://localhost:8080/contact.jsp does not go to the JSP and goes to Restlet. Do deployed app-engine applications respond differently to URLs as their local counterpart?
Restlet doesn't currently support JSPs directly. They're difficult to handle outside of the servlet container.
There's a discussion on Nabble about this issue that you may find useful, at the moment it looks like you need to either return a redirect to the JSP mapped as normal in the web.xml, or hack it to process the JSP and return the stream as the representation.
The response dated "Apr 23, 2009; 03:02pm" in the thread describes how you could do the hack:
if (request instanceof HttpRequest &&
((HttpRequest) request).getHttpCall() instanceof ServletCall) {
ServletCall httpCall = (ServletCall) ((HttpRequest) request).getHttpCall();
// fetch the HTTP dispatcher
RequestDispatcher dispatcher = httpCall.getRequest().getRequestDispatcher("representation.jsp");
HttpServletRequest proxyReq = new HttpServletRequestWrapper(httpCall.getRequest());
// Overload the http response stream to grab the JSP output into a dedicated proxy buffer
// The BufferedServletResponseWrapper is a custom response wrapper that 'hijacks' the
// output of the JSP engine and stores it on the side instead of forwarding it to the original
// HTTP response.
// This is needed to avoid having the JSP engine mess with the actual HTTP stream of the
// current request, which must stay under the control of the restlet engine.
BufferedServletResponseWrapper proxyResp = new BufferedServletResponseWrapper(httpCall.getResponse());
// Add any objects to be encoded in the http request scope
proxyReq.setAttribute("myobjects", someObjects);
// Actual JSP encoding
dispatcher.include(proxyReq, proxyResp);
// Return the content of the proxy buffer
Representation rep = new InputRepresentation(proxyResp.toInputStream(),someMediaType);
The source for the BufferedServletResponseWrapper is posted a couple of entries later.
"I would like to return a JSP file on a URL request through Restlet" - My understanding is JSP's are converted to servlets. Since Servlets are orthogonol to Restlets not sure how you can return JSP file through Restlet.
Assuming you are asking for a way to use JSP in addition to Restlet, This is best achieved by mapping your restlets to a rootpath such as /rest instead of /* and using the .jsp as usual.
Looks like a simple web.xml configuration.
<servlet>
<servlet-name>contactServlet</servlet-name>
<jsp-file>/contact.jsp</jsp-file>
</servlet>
<servlet-mapping>
<servlet-name>contactServlet</servlet-name>
<url-pattern>/contact</url-pattern>
</servlet-mapping>
This works without Restlet in App-Engine. But once I include Restlet, it doesn't work if I set my Reslet url-pattern to "/*"
All,
I'm trying to find out, unambiguously, what method (GET or POST) Flash/AS2 uses with XML.sendAndLoad.
Here's what the help/docs (http://livedocs.adobe.com/flash/9.0/main/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00002340.html) say about the function
Encodes the specified XML object into
an XML document, sends it to the
specified URL using the POST method,
downloads the server's response, and
loads it into the resultXMLobject
specified in the parameters.
However, I'm using this method to send XML data to a Java Servlet developed and maintained by another team of developers. And they're seeing log entries that look like this:
GET /portal/delegate/[someService]?svc=setPayCheckInfo&XMLStr=[an encoded version of the XML I send]
After a Google search to figure out why the POST shows up as a GET in their log, I found this Adobe technote (http://kb2.adobe.com/cps/159/tn_15908.html). Here's what it says:
When loadVariables or getURL actions are
used to send data to Java servlets it
can appear that the data is being sent
using a GET request, when the POST
method was specified in the Flash
movie.
This happens because Flash sends the
data in a GET/POST hybrid format. If
the data were being sent using a GET
request, the variables would appear in
a query string appended to the end of
the URL. Flash uses a GET server
request, but the Name/Value pairs
containing the variables are sent in a
second transmission using POST.
Although this causes the servlet to
trigger the doGet() method, the
variables are still available in the
server request.
I don't really understand that. What is a "GET/POST hybrid format"?
Why does the method Flash uses (POST or GET) depend on whether the data is sent to a Java servlet or elsewhere (e.g., a PHP page?)
Can anyone make sense of this? Many thanks in advance!
Cheers,
Matt
Have you try doing something like that :
var sendVar=new LoadVars();
var xml=new XML("<r>test</r>");
sendVar.xml=xml;
sendVar.svc="setPayCheckInfo";
var receiveXML=new XML();
function onLoad(success) {
if (success) {
trace("receive:"+receiveXML);
} else {
trace('error');
}
}
receiveXML.onLoad=onLoad;
sendVar.sendAndLoad("http://mywebserver", receiveXML, "POST");
The hybrid format is just a term Macromedia invented to paint over its misuse of HTTP.
HTTP is very vague on what you can do with GET and POST. But the convention is that no message body is used in GET. Adobe violates this convention by sending parameters in the message body.
Flash sends the same request regardless of the server. You have problem in Servlet because most implementation (like Tomcat) ignores message body for GET. PHP doesn't care the verb and it processes the message body for GET too.