I am working on a project where we'd like to pull content from one of our legacy applications, BUT, we'd like to avoid showing the "waiting for www.somehostname.com/someproduct/..." to the user.
We can easily add another domain that points to the same server, but we still have the problem of the someproduct context root in the url. Simply changing the context root is not an option since there are hundreds of hard coded bits in the legacy app that refer to the existing context root.
What I'd like to do is be able to send a request to a different context root (Say /foo/bar.do), and have it actually go to /someproduct/bar.do, (but without a redirect, so the browser still shows /foo/bar.do).
I've found a few URL rewriting options that do something similar, but so far they seem to all be restricted to catching/forwarding requests only to/from the same context root.
Is there any project out there that handles this type of thing? We are using weblogic 10.3 (on legacy app it is weblogic 8). Ideally we could host this as part of the new app, but if we had to, we could also add something to the old app.
Or, is there some completely different solution that would work better that we haven't though of?
Update: I should mention that we already originally suggested using apace with mod_rewrite or something similar, but management/hosting are giving the thumbs down to this solution. :/
Update 2 More information:
The places where the user is able to see the old url / context root have to do with pages/workflows that are loaded from the old app into an iframe in the new app.
So there is really nothing special about the communication between the two apps that client could see, it's plain old HTTPS handled by the browser.
I think you should be able to do this using a fairly simple custom servlet.
At a high level, you'd:
Map the servlet to a mapping like /foo/*
In the servlet's implementation, simply take the request's pathInfo, and use that to make a request to the legacy site (using HttpUrlConnection or the Apache Commons equivalent).
Pipe the response to the client (some processing may be necessary to handle the headers).
Why not front weblogic with Apache.
This is a very standard setup and will bring lots of other advantages also. URL rewriting in apache is extremely well supported and the documentation is excellent.
Don't be put off by the setup it's fairly simple and you can run apache on the same box if necessary.
Using Restlet would allow you to do this. The Redirector object can be used. See here and here for example.
If you instead serve out a JSP page you can use the tag to do the request server side.
Then the user will not even know that the resource was external.
http://java.sun.com/products/jsp/syntax/1.2/syntaxref1214.html
a bit more context for the API the client is working against would help here to give a solution that could work. Are you trying to provide a complete new API totally different from the legacy Java EE app? What artifact is serving the API (Servlet, EJB, REST service)?
If you have the API provided by a different enterprise application then I suppose you simply use a Pojo class to work as a gateway to the legacy app wich of cause can then be reachable via another context root than the new service app. This solution would assume you know all legacy API methods and can map them to the calls for the new API.
For a generic solution where you don't have to worry about what methods are called. I am curious if the proxy approach could really work. Would the user credentials also be served correctly to the legacy system by URL re-writing? Would you have to switch to a different user for the legacy calls instead of using the origin caller? Is that possible with URL re-writing. Not sure if that could work in a secure context.
Maybe you can provide a bit more information here.
Related
I am trying to wrestle with SSO in weblogic version is 12.2.1.3. We have integrated it with OAM/OID, within a larger application comprising of Oracle Forms & Reports. In addition to Forms, we have various custom servlet-based applications that need to be called from Forms.
This is fine.
Because authentication happens within the Oracle world, through OAM login screen, up to now I didn't have to mess with the Access Management within my Java custom code, apart from getting the username from HTTP headers.
The bad thing is that sometimes we need our servlets to act as middle-man between Forms and Reports. E.g. I need to call various stuff with Reports (on server), transform them and send them back to the client. I know that this doesn't sound right design-wise. But still it's legacy code and we need to make this work - at least need to try..
Previously we used to get away with it passing cookies between requests. But in 11/12g OAM, I am gathering from here that the cookie needed for successful session validation (OAMAuthnCookie) is stripped from the request before reaching my servlet. This seems to happen indeed, basing on the header dumps i am doing, and tracing calls using F12 Developer Tools on the browser.
So.. I have gathered that I need to generate a new OAMAuthnCookie, or something that would create it and attach it to the new http call.. I just would like an expert or somebody who has dealt with this to verify that the following assumption is right - the only way to do this is using OAM SDK (a bit non-intuitive imho).
Another thing - many of the examples that I find about OAM SDK deal with login forms. I don't need to do user authentication, nor do I need to talk with OAM myself to verify if the resource is protected or not. I am dealing with an already authenticated request - need to just somehow get UserSession and user token from HttpServletRequest, in order to generate new OAMAuthnCookie so that my next request (using e.g. apache client) succeeds.. I used to assume that this wouldn't be hard to do, but am a bit stumped now.
Thank you for your attention.
Working with OAM SDK, as far as I cursively saw (at the time of writing this, we were using Weblogic 12c with Access Manager that behaves exactly as described in the documents that talk about OAM 11g - therefore I assume that's the version we are using too), involves
generating ObAccessClient.xml from OAM Console, to establish contact between the code you are working on (which will be called Access Client), and OAM
including JARs from the downloadable OAM SDK with your application
writing code in your application (e.g. in authentication filter, or servlet) to establish communication with OAM via its SDK to finally authenticate/authorize etc.
There is a good guide about how to write the code in Oracle documentation here.
I found also these articles very informative:
Oracle Access Management blog
Oracle A-team Best Practices blog
The code that I had in mind would ultimately generate a new authentication cookie that I would pass to the reports servlet for further authorization (since this cookie is stripped indeed from the request before reaching my application). The only way I found to generate such a cookie would involve changing a setting in OAM console to include another cookie (OAM_IDENTITY_ASSERTION) in the requests, according to another Oracle A-Team article.
In the process of the above investigation, I finally stumbled on this magic reply to a question in Oracle forums. According to it, there is a user setting in OAM console, that allows to switch off the default filtering of OAMAuthnCookie.
filterOAMAuthnCookie=false
In our case, this perfectly suited me. Indeed after the change, the cookie in question was finally reaching my application, with the result of me being able to pass it to subsequent requests to Oracle Reports, without using OAM SDK.
I am relatively new to JAVA and am trying to build a back-end application which will call another server where the data is present.
I have to do GET, POST, PUT and PATCH(can live without PATCH) operations to an external server in the intranet. I can hit the exposed service using postman app (using custom header)but want to do the similar action from my Java code, get the output in my Tomcat Server.
I have limitations in modifying dependencies to the POM file or adding jars to the library, so am looking for a solution other than Jersey.
You can use HttpURLConnection (which extends URLConnection) to handle the http requests and these classes are part of JDK itself so you don't need any external jar files, I suggest you look here for basics on these and look here for examples.
Most of the places, I look for provides me the answer for GET. I see
some POST too, but my requirement is mainly for PUT.
In order to place PUT, DELETE, etc.. http operations, you can use httpConnectionObj.setRequestMethod("PUT") or httpConnectionObj.setRequestMethod("DELETE") as given in an example here.
you could set up a simple java.net.Socket instance and implement the calls yourself - then you don't need any dependencies.
http://www.cafeaulait.org/course/week12/22.html
java.net.HttpURLConnection seems to be the way to go then. This might i.e. be initialized like so: (HttpURLConnection) new URL(url).openConnection()
I would like to program a WebService embedded on my android device (not the client part).
I've been evaluating Restlet Framework (Restlet) but i don't know if I go on the right way.
What do you think? Is that framework viable for my goal?
Any suggestion is welcome!
Thank you so much!
Regards.
You should check whether Restlet is compliant with android,
not just from server side code, but also from client side code (respectively).
This means for example that every JAR that Restlet framework depends on has to contain code that is compliant with Android.
An alternative approach would be to run a simple HTTP server on your device, for example the following nano http server I read about.
Another interesting project you should check is jetty for android which will hopefully give you support for servlet API as well.
Yes, you will have to spend some time on developing mapping requests and building resource handling logic, but that task is not that difficult:
A. You already have Android code for JSON processing -
For example, look here
B. Using the Java URL object you can analyze the URL of the request and understand which resource you should handle (i.e - add resource to collection, fetch collections, etc).
C. After performing the CRUD operation (i.e - store your resource in some SQLIte table), you can send back a response, and once again, composing JSON if needed is easy.
GWT RPC is proprietary but looks solid, supported with patterns by Google, and is mentioned by every book and tutorial I've seen. Is it really the choice for GWT client/server communcation? Do you use it and if not why and what you chose? I assume that I have generic server application code that can accommodate for RPC, EJBs, web services/SOAP, REST, etc.
Bonus question: any security issues with GWT RPC I need to be aware of?
We primarily use three methods of communications:
GWT-RPC - This is our primary and prefered mechanism, and what we use whenever possible. It is the "GWT way" of doing things, and works very well.
XMLHttpRequest using RequestBuilder - This is typically for interaction with non-GWT back ends, and we use this mainly to pull in static web content that we need during runtime (something like server side includes). It is useful especially when we need to integrate with a CMS. We wrap our RequestBuilder code in a custom "Panel" (that takes a content URI as its constructor parameter, and populates itself with the contents of the URI).
Form submission using FormPanel - This also requires interaction with a non-GWT back end (custom servlet), and is what we currently use to do cross site communications. We don't really communicate "cross site" per se, but we do sometimes need to send data over SSL on a non-SSL page, and this is the only way we've been able to do it so far (with some hacks).
The problem is that you are on a web browser so any non-http protocol is pretty much not guaranteed to work (might not get through a proxy).
What you can do is isolate the GWT-RPC stuff in a single replaceable class and strip it off as soon as possible.
Personally I'd just rely on transferring a collection of objects with the information I needed encoded inside the collection--that way there is very little RPC code because all your RPC code ever does is "Collection commands=getCollection()", but there would be a million other possibilities.
Or just use GWT-RPC as it was intended, I don't think it's going anywhere.
I am very new to creating webservers - and I have had several goes at trying to understand them and write a quick webserver, but it's never quite 'clicked'. At the moment I am under the impression that REST would be most suitable for my purposes (I will explain later).
Can anyone either show me a basic code example in Java (using Tomcat Apache) or a tutorial resource to show how a webserver:
Can be used for security - i.e. pass in some kind of value to identify the client - from their the webserver will either deny or grant access to the client dependant on some criteria - maybe a lookup list.
Once the client is successfully accepted they will be allowed to pass in some more values to the webserver that will be used to write a row in a database table.
Many thanks.
PS - I would have thought there might have been soemthing that comes with Eclipse Ganymede? If someone can confirm?
The best way to write restful resources in Java is via the JAX-RS standard. So I'd recommend you download Jersey which is the JAX-RS reference implementation and check out its examples; its got lots of them. Take an example for a spin then try hacking it to do what you like.
BTW JAX-RS can be run inside any Servlet engine - you just build a WAR and deploy it (there are examples in the Jersery samples) - though Jersey also comes with a small lightweight web server you can use too which is a little easier to use - again there are examples in the distro of this.
I would also suggest that you look at Restlet