I am writing an Android app which submits a username and password to a Java Servlet hosted on Google App Engine. I am writing both the Android app. and Servlet.
The username and password are packaged into a POST request on the device and the servlet doPost() method checks the values. If the username and password are correct I request a session...creating it if it doesn't exist:
HttpSession session = request.getSession(true);
In this session I store a name value pair "logged" and "true".
Back on the android device a cookie is returned along with an HTTP status of 200 OK. This all seems fine, since the session on the server is implemented using cookies (transparent to me since I'm just using the session API).
All subsequent HTTP POSTs made by the android device package up the cookie into the HTTP POST so that it can request .jsp pages or use other servlets which inspect the session for the "logged and "true" value (i.e. protected pages).
The problem: A cookie is returned even if the following code is NOT run:
HttpSession session = request.getSession(true);
i.e. the username and password were false. This isn't such a security issue since the "logged" and "true" name value pair is never set so the application cannot use the .jsp or other servlets. However, I was using the fact that a cookie had been returned from the POST request to the device as a sign that authentication was successful.
Why am I getting a cookie even though I don't use or request the use of a session?
My current solution is to create an additional cookie in the servlet and check for this cookie on the device. HOWEVER, this cookie is not the one packaged into subsequent POSTS from the device since it is not the cookie associated with the session containing the "logged" "true" value. This seems hacky. Clearly I ave misunderstood something.
Most (or perhaps all) servlet containers will always assign a user a session cookie if they do not already have one, whether the webapp being served explicitly requests a session or not. Google App Engine is no different in this regard. You shouldn't assume anything based upon the mere existence or non-existence of a cookie other than that the device has made a request to the server and received some response back.
If you want to verify that the login was successful on the device, why not just send back a response to the login request that it can easily parse. For instance, a simple JSON-snippet like {"status": "success"} would do, or even just the literal text string "success".
Your second cookie approach definitely sounds a bit hacky. Presumably your authentication request is already sending some response back to the device (it has to be, if cookies are being sent). What do you feel that you gain from using a cookie that you don't get by just sending some status message back as part of the response?
Related
I have an application where authentication happens through a passive client. Basically based on server information, a browser will be launched and it will show a login screen. Once the user enters login credentials, the further handling of cookies and session is done in shouldOverrideUrlLoading.
The issue is coming with authentication when I am connecting to web application servers in a clustered environment. When user connects to first server, it shows him login screen and user enters the details, server authenticates, but during session handling in shouldOverrideUrlLoading, my code connects to the same server with same url, but the response from the server comes that user has not been authenticated, while he has already done authentication.
So to differentiate between different servers, we use JSESSIONID to identify server.
I get the original JSESSIONID that was used on the first URL, but when the second URL is fired, my code use JSESSIONID and other cookies from the first URL in the request of second URL. To fire second URL, i use org.apache.http.impl.client.DefaultHttpClient.execute method.
I am not sure what I am missing to get the response from server that user is already authenticated.
I resolved this issue. There was an issue with cookie version, I was using while building a HTTP context for second request.
BasicClientCookie cookie = new BasicClientCookie(name,value);
// cookie.setVersion(1);
cookie.setDomain(host);
cookie.setPath("/");
cookie.setSecure(true);
cookieJar.addCookie(cookie);
I commented version for cookie and then it recognized request to send to same cluster member which was authenticated in first request.
So I want to login to a webpage which uses Basic Authentication to login.
If I send HTTP Get with the Authorization Header, I get the successful response as HTML. But afterwards, it asks me again, to login, because it didn’t remember that I’m already logged in.
So my question is:
How can I save this information, that I have already been logged in?
I know, I already asked that question before, but since no one answered any more on the other thread my last hope was to open another.
The other thread: Android doesnt notice when i do an WWW-Authenticate
EDIT:
So what i wanna do is:
Intent browserIntent = new Intent(Intent.ACTION_VIEW,Uri.parse("The Website with the Authentication")); // Here, i want to add the request header
handler.startActivity(browserIntent);
But i have no idea how, because, the only thing you can send the intent is the Url (and no request headers).
Hope this makes things clearer.
Basic authentication doesn’t save state on the server end. Every request requires that you include the login information.
What happens normally is that:
The browser makes a request for a URL, lacking any authentication.
The server returns code 401, that this URL requires basic authentication.
The browser asks (either the user, or some database of its own) for the username and password. If it asked the user for the password, the browser then stores the username/password in an internal database, keying it against this URL.
For every further request for this URL, the browser includes that username and password in the HTTP GET request.
So the basic answer is, the server doesn’t remember that you have already logged in. The browser remembers that. Since you’re writing the browser, it’s up to you to have your application remember the username/password combination for that URL. Whatever you are doing now after you receive a 401 response, you simply always do for that URL. You don’t even need to wait for the 401 response.
I'm using Parse as the backend.
To check if the user is logged in I use ParseUser.getCurrentUser(). What I don't understand is, if the user changes his password from somewhere else (another device, the web-client), will this ParseUser return with some kind of error?
I don't think it does a check on the server, so I think it just returns the last saved user. This mean that I can continue to use this user (with an old password) or will I get a "wrong credential" response on the first request to the servers?
If I don't get it, will I at least get it when setting an ACL with parseObject.setACL(new ParseACL(ParseUser.getCurrentUser()));?
Try same action on yahoo in 2 open browsers of different types and see what you get?
Each client's been handed a token value by the respective servers and until the token expire will not be prompt for a new logon.
Well IMO Parse work very similar except the lease on Parse token never expire.
Response to the original parse logon contain the token value which the SDK may retain. Details are in the docs section on Rest api / user logon...
So, if a diff client change password but the token lease over on some other client never expire, the other client stays logged in.
I am trying to login to an internal wireless with security. I can do HTTP POST requests, but it doesn't work for this login site. I suspect it has something to do with it giving the user a Session ID, as the login page URL is http://blahblah.com/login/Login.php?sid=(string of numbers and letters).
I have just been trying to POST data to http://blahblah.com/login/Login.php and that is unsuccessful.
So my question is: how do I obtain the SID in order to logon to the site with the correct URL?
you need to parse the response the server is giving you (assuming in fact you need a session ID, not design an oauth process). Most server session ID's are given in xml form. There is a native java XML parser but you can google that and figure out how youd like to handle that. you will probably need to append your session ID to your POST URL as well.
I have an issue with wifi connectivity when a browser form must be completed before internet access is granted. The user (if using a browser) is redirected to a login form requiring them to login or sign up for wifi access.
The users are not using a browser but a request from my app to the server is redirected to a login form making the server unreachable. Is there a graceful way of detecting this behaviour and at least warning the user of the issue..
In many cases the mobile network is available and switching off wifi is all that is required.
An HTTP redirect has a specific response code (well, several specific response codes, from 300 to 307). You could read the responseCode before assuming that you have a connection and handle the failure from that point.
A redirect should also have a Location value in the response header, so you could conceiveably capture that value and launch a WebView, passing Location as the URL, giving the user access to the login form. This would get a little complex, though, depending on how the session is validated - if there's a cookie, for instance, you'd have to extract it from the form response and store it for future requests from your native code. Often these sessions employ the MAC address, in which case you wouldn't have to do anything else (apart from handle a successful login and try your request again).
I hope that's helpful.