Can GWT RequestFactory calls be cookie-parameterized? - java

I understand that with GWT RequestFactory, server-side calls are all made to a RequestFactoryServlet. I'd like to write a GWT application (using RequestFactory) that looks to a cookie to determine which base URL all server-side calls are made to.
So, I'd have 3 different WAR files deployed to 3 different Tomcat instances living on 3 different physical servers, mapped to 3 different IP addresses (URLs). Each WAR would have a RequestFactoryServlet defined and would be capable of servicing requests from the same GWT client.
But, on the client-side, if a widgetType cookie has a value of red, I want all server-side requests to go to:
http://red.example.com/RequestFactoryServlet#doGet
If widgetType=blue, then I want all server-side requests to go to:
http://blue.example.com/RequestFactoryServlet#doGet
If widgetType=orange, then I want all server-side requests to go to:
http://orange.example.com/RequestFactoryServlet#doGet
So, in summary, the client-side cookie (widgetType) determines which RequestFactoryServlet on which WAR/server/URL the HTTP requests get sent to and processed by.
Is this possible? If not, why and is there anything that I can do here? If it is possible, how is it possible (what code/techniques/etc do I need to utilize)? Thanks in advance!

Same-Origin potential issues put aside, all you need is to initialize your RequestFactory with a custom RequestTransport. The easiest is to extend DefaultRequestTransport and initialize its setRequestUrl depending on the cookie value.

Related

how to set the parameter targetURi dynamically in HTTP Proxy Servlet

Good morning, I decided to create a http proxy servlet because I'm in a network where almost all pages are blocked, there is a firewall that blocks almost all called fortinet.
My idea is to use a server that I have which is not blocked, but on that server only have installed an archive of web applications (glassfish) and want to create a web application that serves me as an intermediary between the pages you wish to visit and my pc and thus navigate freely without restrictions.
So far I have used the HTTP-Proxy-Servlet project
The problem is: apparently only connects to a single web that previously we configure the web.xml file with the parameter targetUri
<init-param>
<param-name>targetUri</param-name>
<param-value>http://solrserver:8983/solr</param-value>
</init-param>
How to change this parameter dynamically and navigate as a common and current online proxy?
To implement a "real" proxy (not just a "fixed URL" one), you need to use the getRequestURL method to get the real URL which was requested.
For example, in HTTP-Proxy-Servlet, when he writes:
String proxyRequestUri = rewriteUrlFromRequest(servletRequest);
You can write:
String proxyRequestUri = servletRequest.getRequestURL().toString();
I'm not saying that's the only change you'll have to make, but it's a start.
Alternatively, you could reconstruct the URL using the other getters from the request:
getScheme (http, https etc)
getServerName
getServerPort (which might be 80)
getRequestURI
getQueryString or getParameterNames / getParameterValues
(For some reason, when you type "java proxy servlet" into Google, the first result that comes up is HTTP-Proxy-Servlet. However it's not actually that useful IMO, because it only directs to a fixed URL as you mentioned.)

Explicitly set JSESSIONID

So, I'm in the middle of building an application where I want the user to be able to send a link to another user and work on the same data. There is little need to persist the data for more than 15 minutes and I want the application to not have to rely on a database.
I have a few variables which I am currently storing in a HttpSession.
Ideally I'd like to be able to set a parameter "sid" in the URL, and use that to set the session ID on the second client's browser - the one that's received a link with the SID.
Unfortunately, there seems to be no way to change the SID of a current session once it's been set up.
The only solution I've come up with so far is referring to the doGet() with a HttpPost.setHeader("Cookie", "JSESSIONID="+ getSessionId()) method, and getting the data with a specific session that way, but this seems pretty clunky.
Any suggestions?
EDIT
This has seemingly turned into a discussion about the wisdom of setting two users up to have the same session so session vars may be kept the same. Note that a non-db, ie light weight solution was what I was looking for. PHP allows you to arbitrarily set a session ID to do this, but I'm deploying to Tomcat in this instance. Something which allows lightweight sharing of a few parameters, that's it...
What I've done, then, is to set context vars using context.setAttribute(). Ugly as sin, but all I can come up with, unless anyone has any better ideas.
This approach has some security issues because you are simulating [session hijacking] with it 1:
In computer science, session hijacking, sometimes also known as cookie
hijacking is the exploitation of a valid computer session—sometimes
also called a session key—to gain unauthorized access to information
or services in a computer system. In particular, it is used to refer
to the theft of a magic cookie used to authenticate a user to a remote
server. It has particular relevance to web developers, as the HTTP
cookies used to maintain a session on many web sites can be easily
stolen by an attacker using an intermediary computer or with access to
the saved cookies on the victim's computer (see HTTP cookie theft).
Better approach is to set your data in a way that both users can approach it from their sessions. If you are using single server you can do that with some global data within a server. In clustered or cloud environments you'll need some common storage for that (ie. database, global cache, etc.)
EDIT
You are on a right track to share data among two users with different sessions.
There is one context per "web application" per Java Virtual Machine
where an attribute allows a servlet container to give the servlet
additional information.
Attributes are meant to be used to share data inside container among servlets of the same web application.
For clusters:
In the case of a web application marked "distributed" in its
deployment descriptor, there will be one context instance for each
virtual machine. In this situation, the context cannot be used as a
location to share global information (because the information won't be
truly global). Use an external resource like a database instead.

JSONP or other alternatives?

I a deveveloping a web site that comunicates with a custom made webserver by me in Java. The web site is made in PHP/JavaScript/JQuery running on Apache and i made a simple second webserver in Java to support some designed features by me, and this server runs under another port XXXXX. The problem is, i want to make requests in jQuery to second server the domain is diferent, the page runs on domain and the $.getJSON function calls domain:XXXXX wich is not allowed. I thought user $.getJSONP but im concerning concerned issues. The connections between two points is authed (i was think by passing a token beyond the callback generated by jquery). The two poins are supported by. Is there safe in this case use $.getJSONP or exists other alternatives thinking in browsers support(IE7+ and FF3+).
Sorry for my english :)
Best regards lealoureiro
JSONP should work for your needs, however your other option would be to have a proxy service on your second server that would make the request server side. Your client-side code could then access all the data natively via json instead of jsonp.

Can I write a Java loader class that will hook HTTP requests in the loaded class?

I have a class that I want to hook and redirect HTTP requests in.
I also have a loader class already written, but all it does it replace the functions that contain the HTTP requests I want to change.
Is there a way to hook HTTP requests in Java so that I can redirect them all more easily?
Sort of like a proxy-wrapper.
Clarification:
The app sends out a GET or POST request to a URL.
I need the content to remain the same, just change the URL.
DNS redirects won't work, the Host HTTP header needs to be correct for the new server.
PS: This is a Desktop App, not a server script.
A cumbersome but reliable way of doing this would be to make your application use a proxy server, and then write a proxy server which makes the changes you need. The proxy server could be in-process in your application; it wouldn't need to be a separate program.
To use a proxy, set a couple of system properties - http.proxyHost and http.proxyPort. Requests made via HttpURLConnection will then use that proxy (unless they specifically override the default proxy settings). Requests made using some other method like Apache HttpClient will not, i think, be affected, but hopefully, all your requests are using HttpURLConnection.
To implement the proxy, if you're using a Sun JRE, then you should probably use the built-in HTTP server; set up a single handler mapped to the path "/", and this will pick up all requests being sent by your app, and can then determine the right URL to send them to, and make a connection to that URL (with all the right headers too). To make the connection, use URL.openConnection(Proxy.NO_PROXY) to avoid making a request to the proxy and so getting caught in an infinite loop. You'll then need to pump input and output between the two sockets.
The only other way i can think of to do this would be to override HttpURLConnection with a new handler which steers requests to your desired destination; you'd need to find a way to persuade the URL class to use your handler instead of the default one. I don't know how you'd do that in a clean way.
While an older post, this should give some ideas of some kinds of bytecode injects which can be peformed: Java Programming: Bytecode Injection. Another tool is Javassist and you may be able to find some links from the Aspected-oriented programming wiki article (look at the bytecode weavers section).
There are some products which extensively dynamically modify code.
Depending upon what is desired, there may be ... less painful ... methods. If you simply want to 'hook' HTTP requests, another option is just to use a proxy (which could be an external process) and funnel through that. Using a proxy would likely require control over the name resolution used.
you can use servlet filters which intercept the requests, the requests can further be wrapped, redirected, forwarded or completed from here.
http://www.oracle.com/technetwork/java/filters-137243.html
Do you control all of the code? If so, I suggest using Dependency Injection to inject the concrete implementation you want, which would allow you to instead inject a proxy class.
If you can change the source code, just change it and add your extra code on each HTTP request.
If you can't change the source code, but it uses dependency injection, perhaps you can inject something to catch requests.
Otherwise: use aspect-oriented programming and catch to URL class, or whatever you use to do HTTP requests. #AspectJ (http://www.eclipse.org/aspectj/doc/next/adk15notebook/ataspectj.html ) is quite easy and powerful.

GWT RPC Cookie authentication

I'm using gwt on my glassfish server, and I'm attempting to make some of my RPC calls authenticated via cookies. Is this possible? Are there any examples out there of how to code it?
Depending only on the cookie for authentication will make your website/services vulnerable to Cross-Site Request Forging/XSRF/CSRF attacks - read more on that in Security for GWT Applications.
The best way would be to double check the value you get from the cookie and with the one that's been transported to the server by some other means - as part of the request (header, a custom field, etc).
Other than that, there are many tutorials covering the subject - just search for Java (servlet) authentication - it doesn't have to be GWT-specific. The Google Web Toolkit Group also has many threads about the subject.
I assume that you use GWT's RPC servlet for handling requests made by the client.
One option that comes to my mind is to write and configure a ServletFilter which can examine the cookie, before the request reaches GWT's servlet.
You might rethink using cookies as it is a potencial security hole.
Why not put your communication to HTTPS?
Can you not just use the standard 'session' scope, i.e.
request.getSession()
A pattern I use in GWT apps is to have a separate 'old fashioned' login form which sets up the session. The GWT app's host page is then displayed after they have successfully logged in.
If the necessary values aren't in the session, then the user isn't logged in. Your service should return an exception, maybe, which instructs the GWT app to redirect to the login page, or display an error.

Categories

Resources