Beta program site separation - java

I have a site and i need to create a beta program for it. The idea is separate it in two distinct sites, one running stable application and the other the beta application.
The problem is that the URL to access stable or beta applications has to be the same and based on some rules, like header value, request body or query param the request will be forwarded to the correct site.
I tried Apache mod_proxy module, but it doesn't have the option to create specific rules, like those i need.
Can you help me with it? Any ideas how to implement that?

You can use Nginx as the front end server. And configure it to redirect to stable or beta on base of header value.

Related

How to secure a REST application?

I'm building a REST application with spring, and would like to secure the methods as they will be reachable both within the intranet and later on by some customers.
All requests are GET only. How can a basic, yet strong enough security be implemented? An additional get parameter like ?key=12345 where each customer gets his own key?
Or how could this be done?
First, if you pass the parameters as the query params in the URL, anyone can see the value of the parameter with a sniffer.
You must pass these parameters in the header, using SSL. Thus, these parameters are unreadable with a sniffer.
EDIT:
As kevin say this information is not visible from a sniffer. Only the server IP. But still unsure by:
Full URL (with sensitive data) are stored in the browser history
Full URLs are stored in web server logs.
Full URLs are passed in Referrer headers.
Hello there are many points when you are building a REST application,If something is related with security I recommend you to check OWASP, check the link to analyze what do you need to care for.
Talking about frameworks it depends of your architecture, some of the frameworks that I recommend you to analyze are the next:
Spring security
Apache shiro
Stormpath
Apacheds
I hope that It helps you.

Google endpoints can't request HTTP PATCH at localhost

Google auto-generates and HTTP PATCH endpoint when you code an HTTP PUT
But this PATCH endpoint doesn't run at localhost
The HTTP answer error code is 404
At GAE production server you don't have any problem
It makes himself, two consecutive calls: GET and PUT
Anyone is running PATCH at localhost ?
I planned to use that (and MERGE as well) but will now be careful. GET followed by PUT looks like a hacky workaround. Unfortunately all you can do is add your star to Support for HTTP PATCH and similar feature requests, and try to lobby others to do the same (I've added my vote).
Away from the Endpoint library I hope to implement doPatch and doMerge in an OpenData compatible servlet, and then hope that Jetty connects the HTTP requests from jQuery ajax to those methods. You might be able to try something similar by editing the generated Endpoint library, but that approach might encounter more problems. I'd appreciate feedback on how you fare.

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.

Single Sign On without cookies in Java

I keep on facing this question from my manager how SSO will work if client disable cookies but I don't have any answer. We are currently using JOSSO for single sign on. Do we have any open source framework which support single sign on without using cooking mechanism.
In the absence of cookies, you're going to have to embed some parameter in each url request. e.g. after logging in you assign some arbitrary id to a user and embed that in every link such as http://mydomain.com/main?sessionid=123422234235235. It could get pretty messy since every link would have to be fixed up before it went out the door which slows down your content. It also has security, logging and session history implications which are not such a huge deal when the state is in a cookie.
It may be simpler to do a simple cookie test on logged in users and send them off to an error page if they do not have cookies enabled.
The CAS project passes a "ticket" from the sign on server to the consuming application as a url query parameter, the consuming app then makes a back channel request back to the sign on server to validate the ticket's authenticity. This negates the need for cookies and therefore works across domains however it is a bit "chatty"
Another arguably more robust solution is to use a product based on SAML which is an industry standard for cross domain single sign on. There are a couple of open source products out there which use SAML and CAS itself has a SAML extension however they are typically quite complex to setup. Cloudseal is also based on SAML and is much simpler to use. The Cloudseal platform itself is delivered as a managed service but all the client libraries are open source
Of course with all these solutions you are simply passing a security context from one server to another, the consuming application will no doubt create it's own local session so you would then need to use URL rewriting instead of cookies
Disclaimer: I work for Cloudseal :)

Flex file upload with HTTPS and JAAS?

We're trying to upload a file from a flex client to a Java EE app.
In a full HTTPS environment
Java EE server is JBoss 5
Using BlazeDS 'Custom' authentication (username and password are entered trhough a flex form)
Using BlazeDS per session authentication
In regular AMF calls, we can access user principal and use role mecanism.
However, in our upload servlet, we have no access to user principal.
request.getUserPrincipal() // returns null
How to fix this ?
A while ago a guy commented on a blog post of mine that https + flex + firefox doesn't work:
have you tried uploading a file in firefox via https? Well, don’t bother, it can’t be done! Adobe blames it on firefox and puts their head in the sand. Read the teeth gnashing and ridiculous claims of Adobe here:
http://bugs.adobe.com/jira/browse/FP-201
Ultimately they threw up their hands and said it couldn’t be fixed, and, although said ‘We understand that this is a serious issue and are committed to resolving it’ suggested that either you:
1) Send the file to your server in a different way
2) Find another form of authentication
This may no longer be the case - register and see if the linked bug is still unresolved.
Also - this might not be your exact issue (at least not yet) - I'm just giving pointers.
From your post, and since I haven't used BlazeDS, I can't tell whether you're running into this issue specifically, but it sounds to me like you are --
Take a look at your server logs, or try using a Web debugger like Fiddler (you can tweak it to reveal HTTPS traffic in clear text), and you'll see that Flash blocks custom HTTP auth headers with FileReference.upload(). Why it does, I've no idea, but there's no workaround I know of, other than crafting something or your own manually.

Categories

Resources