Now I have a problem:
user opens web app page, gets javaScript (ModuleName.nocache.js);
Then I update client side (roc requests, view etc).
user didn't close web app tab in browser, didn't update page. He clicks somewhere and gets random explosion. For example, RPC doesn't work, servlets moves anywhere, there is many errors or not.
Now I want to implement scenario:
User must have cookie attribute with web app version.
By request I see it and in response force him to update page (don't know how).
If user's request can't be delivered gwt force him to update page (don't know how).
But I think there must be a best-practice-way to solve this problem.
Catch IncompatibleRemoteServiceExceptions and StatusCodeExceptions in your AsynCallbacks. The first one tells you the client-side code is not compatible with the server-side code; the second can tell you that there no longer is a RPC servlet there (look for a 404 status code).
You can then show a message to the user prompting him to reload the page (this is what Google Groups does for example).
That said, there are some ways to mitigate this if the changes are relatively small: you can keep the old serialization policy files around server-side so the server can process requests from different client versions. The changes have to be somehow backwards compatible though.
You could then detect the client version on the server-side (either using a list of the latest serialization policy files and checking whether the client is using one of them or an older one; or using a request header or cookie) and include something in the response (response header or cookie) telling it there's a new version.
Or you could regularly poll the server (obviously not using RPC though) for the latest version of the app.
Another approach:
If it is empty (if not, go to next step), save the com.google.gwt.core.client.GWT.getPermutationStrongName(); in your LocalStorage or in your Cookies and finish the flow.
When your app loads, get the permutationStrongName again, and check if the saved one is different.
If it is different force to request to the server everything (if you want/need "break" async process you can use GQuery - promises). Then, replace in your LocalStorage or Cookies the new gwt's permutation id.
You can do this always that your app is loaded (is not a big deal). And you can now when the version on your server has changed.
Related
Let's say I've created a mobile application named 'Foo'(iOS). This app talks to a Java-running backend at 'java.com' and works perfectly. Now, I'm trying to create the website 'Foo.com' to let users enjoy the 'same' service on a browser/computer. So far, I've found that almost all calls needed to the API from the website can be done in JavaScript directly to the backend at 'java.com', including a login-function.
On the backend, I've implemented the standard 'doPost'-method to handle the login, and I create a Cookie to attach to the request.
The problem, I think, is that the users get the JavaScript from 'Foo.com', and the JavaScript tries to log in by using an AJAX-call to 'java.com', thus the cookie will be 'stamped' by www.java.com', not by 'www.foo.com', and the user will never receive the cookie. (At least, I don't receive a cookie now)
I've been trying to find a way to accept cookies from 'api.com' into the application, but it doesn't look good. Honestly, I'm not even sure this is the actual problem causing me to not receive a cookie, but I've read several places that cross-domain-cookies aren't allowed. So I ask the general question, how should I proceed?
I've been toying with the idea to add a .php-page to the server-side of the website 'foo.com', and from there handle the requests from client to API, hopefully causing the cookies to be 'stamped' as 'foo.com' instead of 'java.com'. (In that case, I'd also wonder if the .php can forward the information in the cookie or something similar).
But I really want to avoid as much traffic on the webhost as possible. An all-script-website would be optimal, but I don't really see how cookies can work with that.
Is there anything else I can do to handle this? If I simply want a persistent login-function from a client of 'foo.com' handled at 'java.com', are there any options, with or without the use of cookies?
I am new to web app development.
Basically, I have got a GWT based web app. A user first needs to login. After successfully authenticated himself, he will be taken to the second page (actually another GWT view in the same page).
The login will generate a pair of keys from another web service. These key will be used for future communication with the web service, it is like:
client -> server => web service
Now the problem comes, I cannot save the key pair in a database. What shall I do?
I have been told I can put the key in a cookie and send back to the client. Every time the client raise request the cookie will be sent to the server.
I have also been told to set the keys as the session key and send them to the client.
I am note quite sure what is the different between these two methods. Are they applicable? or secure?
Many thanks
Both methods are applicable. The first one (using cookies) will rely on the user side (its cache). Second one, will keep data on server side (session). As a rule (although it's arguable), you never trust the client. What if client made a clear cache to his browser.
Even for security (I am not an expert here), I think storing data on server is always safer.
You can use both cookie as well as session or a combination of both to achieve this. Cookie are usually created when you launch your application (Also you can create it as and when required). The disadvantage of this is, it is temporary. As soon as you clear the cache or cookies, whatever cookie you created will be removed. If you store it on server side i.e., in session you must make sure to create a separate key value pair for each set of user, as many users can connect to the same server. The best approach will be using both the option together. I.e., to save a cookie and validate the session id.
This link will help you understand how create a cookie and session.
I'm working on a Java REST server serving an iPhone app. Now we have to integrate with third party service exposed by oauth2 protocol. This is new to me so I've been reading and writing some "proof of concept" code but I have a big problem or I fundamentally don't understand something...
I made a simple web page with "log in with XXX" button that the user sees in a web view. When he clicks it, login page of the third party service opens and he can approve my app, at what time they will redirect the user to an URL I've specified with the authorization code as a parameter. This URL points to a REST service on my server.
The problem is that this URL must be absolutely the same as the one I've set up when applying my app for their service. Since I'm running a REST server I have no way of knowing about which user are we talking about when the redirection to my server happens (there is no session). I wanted to do this identification with some query or path param but they are not allowing it.
Does any of this makes sense to you or am I implementing this in a wrong way? The only possible solution I can imagine now will be with the help of cookies but I'm not really fond of that...
Yes, that does make sense. You got a few different options, try one of these:
Store a cookie with some user id and read it out after redirection
Use the state parameter of the authorization request for transmitting some user id. The provider is required to return it back to you in his redirect.
I'm building an app to let users export data from a university system. Currently, they can log in and see the data in HTML, but I would like to let people download it as CSV.
I have an app where users supply their username and password. I would like to log in to the university system and HTML scrape the resulting page. How can I do this?
I'm building a GWT app. I could either do this in Java-transliterated-JS on the client, or Java on the server.
Update: Selenium might be nice, but it looks like overkill.
You're going to have to do this from the server unless the domains are the same. You'd need to determine what the POST transaction used by the other server for the login step looks like - parameter names etc. Then you'd perform that operation and do whatever you want with what comes back. If you need to see multiple pages, you need to maintain the appropriate session cookie too so that the server knows you're still logged in on the subsequent HTTP requests.
If you have to hit another site to validate the credentials, then I'm not so sure that people should feel comfortable providing those credentials to you. That is, if you don't have rights to check the credentials directly, why are you trustworthy to receive them? I know sometimes people need to integrate with a system they don't own, so this is just a question.
First, this has to be done server-side because of the limitations on client scripting due to the same origin policy.
The typical way of handling the "screen scraping" you mention is to treat the web page as if it was an XML service. First, examine the source code of the page, then using an internet/HTTP stack, craft a POST to the correct URL and read the response using a standard XML library. It will take some ingenuity to come up with a good way to dig into the XML to find the piece you need that will be as insulated as possible from changes to the page. Keep in mind that your system can break any time that the owners of the site change their page.
Sometimes, you can't just send the POST but have to request the blank page initially in order to get hidden form values that need to be returned in the POST. You'll have to experiment to find out what it requires.
Additionally, you probably have to handle cookies as well, since they usually are an integral part of the web site's authentication and session management (though you might get lucky that the session doesn't matter between the initial POST and the first response).
Last, you may be unlucky enough that the site uses javascript to do part of the authentication work, which may require additional digging to understand how the credentials are posted to the site.
There are other potential barriers such as the site checking to see that the referrer is their own site, possible use of SSL (HTTPS) and so on.
I'm pretty sure that the protection against cross-site scripting in web browsers will mean that you can't log in to the university's app using javascript running in the web browser. So the part of your program that fetches data from the university will need to run on your server. Once you have the data, you can process it either on your server or in javascript in the browser, but I think it would be easier to do it on the server.
See http://en.wikipedia.org/wiki/Same_origin_policy
I'm not too sure about GWT, but in general, you would take the form data submitted by the user, check it against a database of username and hashed passwords. If the database checks out, set a session cookie that says the user is logged in.
In your pages, check if the session cookie say the user is logged in. If not, redirect to login page, otherwise allow them to view the pagfe.
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 :)