Can we use GWT RPC Servlet as Oauth callback URL? - java

I am thinking if its possible to user a GWT RPC Servlet (like MyServiceImpl) as callback URL for oauth? The oauth provider will call the callback URL and then pass URL parameters to that callback, is it possible that capture those URL parameter in the RPC servlet?

It is possible to do something like this. RemoteServlet is just another normal servlet, you can override its doPost() and doGet() methods. You will just need to filter incoming requests, if it is an Oauth callback handle it, if it is GWT-RPC request (you can find this out by checking for specific GWT HTTP headers), just delegate it to the super class.
But in reality it is better to keep those two things separated. There can't be a real reason why one servlet should be handling Oauth callbacks and GWT-RPC requests.

The deserialization that GWT uses would make this pretty tricky. It also has a lot of restrictions through it's whitelisting of the exact way in which data can be read from the request. You would probably be better off to override the 'service' method and intercept any oauth callbacks before GWT gets to them.

Related

Jersey: Display possible actions on a resource

I am using the Jersey implementation of JAX-RS spec to develop RESTful web services. There is a url that can uniquely identify a resource. Is there a way to let know the user of the RESTful services, the possible actions that can be performed on the resource? For example,
Resource name - host1
http://localhost:8080/state-fetcher/rest/object/host1/actions
This should give me all the possible actions that can be performed on the resource - {actions: [GET, POST, DELETE]}
Thanks!
Use the OPTIONS HTTP method on the resource. You will get the allowed methods in Allow header, for example: Allow: GET, HEAD, PUT and in a payload you will find the fragment of wadl associeted with the specified resource.
A RESTful service itself is inteded to be self- descriptive! If the user performs a request, the REST service should send back a list of possible links, which can be performed next, along with the response. That's the motivation and general concept of a RESTful serivice. If you provide a graphical WebClient, you just need to provide the initial link (e.g. http:\example.com\restful), and the response sends back a list of valid links which just needs to be visualized within the GUI. Usually the webservice only provides those links which are accessible in terms of the users role. (This is not a security feature!!! It just prevents that unecessary links are displayed) Otherwise the OPTION method of the HTTP protocol provides information concerning the supported protocol methods.

HttpServletRequestWrapper and Filter lifecycle in tomcat

I am coding a Tomcat application and am authenticating against Google's oauth2 services. I was originally going to write a simple Filter to do the authentication but there is no way to set the user principal in a Filter. From my understanding you have to have the Filter call an implemented HttpServletRequestWrapper and set it inside of that class as seen in this post
I'm pretty sure Tomcat only instantiates one Filter of each type you may have defined and all requests go through this single object down the Filter chain (correct me if I'm wrong).
In the linked to code, is it correct for the code to call
next.doFilter(new UserRoleRequestWrapper(user, roles, request), response);
where every request is instantiating a new UserRoleRequestWrapper? Should this Filter instead have one request wrapper instatiated that gets shared amonsgst all requests? I'm having a hard time finding documentation on the specs of classes such as these.
I don't think that a Filter is what you're looking for. Doesn't seem right for this purpose... Filters weren't created for such use cases; they were created for pre/post processing requests and responses, with emphasis on manipulating the actual request/response data, rather than other aspects of the client-server communication (such as security). Remember, authenticating a user may have further repercussions than just handling HTTP request cycles. Security ties into the JavaEE framework in a lower level than HTTP cycles.
If you want to authenticate against oauth2, you should be far better off implementing some sort of a JAAS implementation for it, and plug it into Tomcat.

Calling servlet from servlet

I would like to call a servlet from another servlet doing two things:
setting the content type to "multipart/form-data"
setting the method to "POST".
This is very easy to do from a form, but I need to do it from another servlet. Any ideas how?
You can use java.net.HttpUrlConnection or maybe Apache HTTP client to send a POST/GET request to the other servlet. You will basically be invoking the other servlet the same way a browser would.
It sounds like request forwarding or include is what you're looking for. What you actually do will depend on what you intend to do with the output of the target servlet. Are you going to display it somehow? Or are you simply discarding it? You may in some cases, need to be a bit more "creative" in how you invoke those methods (e.g., either creating your own request/response instances, or wrapping the current request/response so that state changes are isolated).
Alternatively, to keep things simple you may want to just open a network connection to your target servlet's mapped URL as Jeff suggested.
It sounds like you want to send an HTTP POST with java. I would recommend using apache HttpClient. Check out this question Add parameters to Apache HttpPost
You can also do this with pure java with (HttpUrlConnection)[ http://download.oracle.com/javase/6/docs/api/java/net/HttpURLConnection.html].

Calling Servlet Post from another Servlet

I need to call a servlets POST method from another servlet and pass a blob in the servlets parameters. Is this posible, if so how can it be done. PS: I cant use Apache HttpClient
You need to create and send a HTTP request yourself. You cannot make use of forward/redirect/include because you want to change the method from GET to POST and you want to send a multipart/form-data request.
As HttpClient (and other 3rd party library?) is apparently not an option, your best bet is to use the standard Java SE API provided java.net.URLConnection. Long story short: Using java.net.URLConnection to fire and handle HTTP requests At the bottom you can find a multipart/form-data example.
Please note that this problem is not specific to servlets. In other words, you must be able to execute this code in a plain vanilla Java application with a main() method. This allows for easier testing and finetuning. Once you get it to work, just let the servlet execute the same piece of code.
Unrelated to the problem, I have the impression that there's a major design failure somewhere, certainly if the both servlets runs in the same webapplication context. The other servlet where you want to send the POST request to is apparently too tight coupled and should be refactored.
You can get a dispatcher to another servlet in your application and forward it or include it as #Ryan suggests. The code should be something like this inside your first servlet:
ServletContext context = this.getServletContext();
RequestDispatcher dispatcher = context.getRequestDispatcher("/otherurltoservlet");
// change your request and response accordingly
dispatcher.forward(request, response);
Do you mean call from your application to another web service? If so, then something like HttpClient is what you want. If you mean you want to programmatically invoke another servlet in your app, then you're looking to either forward to it or include it.

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.

Categories

Resources