(I'm asking this partly for learning purposes, I realize what I'm trying to do might be entirely wrong!)
I have a php file on my website that handles log in and sets a cookie for the user if log in is successful. if setcookie() fails, I error out instead of displaying the rest of the page.
When I try to access this page using my android app (which uses HttpURLConnection with POST), the setcookie() fails. I'm guessing this is because the client isn't a browser and can't handle cookies.
so first of all, is there away for my app to be able to receive cookies from the server and store them? if not, how do you handle maintaining a login session with the user so you dont have to send a username and password, every time you want to access data from the server?
THanks
A couple of notes before the workaround:
The function is called setcookie() not set_cookie()
Android browsers do support cookies afaik, so you probably should look into this further. Perhaps the format of your setcookie call is not valid?
If you can't use cookies, then the workaround is to simulate your own session mechanism by passing your cookie value as a url parameter on every request.
Related
I have a node js server and an android client. Basically I have two options for authentication: rest api + http basic or sessions. I prefer sessions, because storing user credentials to the memory of a phone doesn't seem like a good idea. Session id is temporary, so storing it would not be a security issue.
I've tried the following approach: On node js I'm using express-session middleware. On client side, session id is stored in variable SID. With every request, cookie "connect.sid=SID" is set. If response contains set-cookie, SID is set to match connect.sid. However, this approach does not work. I could however generate my own id and not use express at all.
Also, I don't understand browser behaviour with express sessions. I'm using https, if that makes any difference. It works fine, but first of all, all requests create 2 operations: one with OPTIONS method and the other with the actual operation. The response to options request returns set-cookie. In actual operation requests, cookie "connect.sid" is set. In every request the id is same BUT each set-cookie returned by the server has a different id and the id sent by the client does not match any of these ids. Could someone explain what's going on?
Authenticating to a server with a mobile application is a very common situation these days. What is the recommended way to handle it (without third parties)?
Could someone explain what's going on?
I suspect that your implementation of the cookie handling in the client-side (Android app) could be the cause of the problem.
I developed an Android app with node.js and I saw a similar problem using an RESTful API.
In my case, I used the Retrofit2 REST library. This library is based on OkHttp3 API for dealing with HTTP request/response. To solve my problem with cookies, I included the code showed in the answer https://stackoverflow.com/a/34886860/7183182, where the main pieces were the PersistentCookieStore implementation and the JavaNetCookieJar class. If you use the HttpURLConnection, the PersistentCookieStore implementation can be passed to CookieManager. The Android documentation shows how to use specific CookieStore implementations here and here.
Authenticating to a server with a mobile application is a very common situation these days. What is the recommended way to handle it (without third parties)?
I recommend use the OAuth solutions, where the API key (or access token) is stored in the client-side using SharedPreferences.
Session id transported through cookies is an solution, but it is problematic with native or hybrid mobile applications.
I want to make an android app which will login to my web application using rest API. In browsers we have a concept of cookie which servers use to identify/maintain session with the users.
In Android how would we accomplish it ? I heard that there is a concept of token which is sent by server in response(first time when credentials are validated) and Android app have to send it to server every time it tries to access a resource(protected). So, what is the better way of doing it ?
Do we need to validate the token again and again when the client requests for a resource ?
Honestly, I can't think of a better way of doing this. Token based authentication seems to be pretty standard when dealing with RESTful APIs. Is there any reason you can't do that?
If you don't want to change the server code, then this could be simulated by adding a cookie header to every request you send. But this is basically the same thing that you mentioned above, just not as clean.
And the browser is already sending a token to be validated again and again. Every request has a cookie header that gets validated through your web application on every request, so this isn't a big deal at all.
And, you don't need anything Android specific to accomplish this. In whatever http library you're using I'm sure there is a method you can called or something you can override in order to set custom headers. Use that to set either your cookie header or token header on every request that you need to make.
I am using CouchDB to authenticate users for my app, which is essentially just a front end for a CouchDB database, so I am using the API to authenticate users, logically, this code
httpget(http://wrongusername:wrongpassword#mycouch.com:5984) //not my actual code
should come back with the response
{"error":"unauthorized","reason":"Name or password is incorrect."}
as it does when I cURL the same URL. But instead, no matter what I put in as the username and password it returns
{"couchdb":"Welcome","version":"1.2.0"}
And I know I'm not somehow storing a valid URI or that response in the code because I've changed the parameters of HttpGET to return _all_docs, and it has returned all the documents, which a normal user shouldn't be able to to do. I have not modified any of the configuration files and the login is not stored anywhere in the database
Are you sure you are hitting the same CouchDB instance that you have set up the users with? Clients, not even Android, have a way of bypassing authentication.
Couchdb uses session cookies for authentication, maybe your http client authorized to couchdb before and keeps the cookie around?
Another thing I can think of: unless you set require_valid_user to true, couchdb only restricts access to individual databases, which would explain the "welcome" message on /.
I am working on a web application for android phones, which is basically few js and html files packaged using Phonegap for android. I am making http requests to the server, getting some cookies (whose life is 10 yrs). These cookies are set by the response header. Now this works fine for this session, the set cookies are sent with each request. But if a quit the app and restart it, the cookies vanish, and are not sent with the request.
The life of the cookies is 10 yrs. Shouldnt they persist? Please tell me where i am getting it wrong?
EDIT-- I tried saving the cookie in an sqlite db, and then setting it properly in document.cookie before making the ajax call. Still its not being sent. Any ideas...?
Cookies wont persist after the app is closed. Also you cannot directly set the cookies in an xhr object using javascript, according to w3c specifications, so thats why i wasnt able to do that. the solution would be to re-perform the actions which set the cookies in the cookie jar in the first place.
I want to make a login application in Android.
Requirement of the project is to store user name and password for two days using cookie.
Is it possible to use cookies? If yes, then how? Can you give me the code?
Note: I can't use web view.
As a commenter already said, you aren't supposed to store password (even in encrypted form) in a cookie. What you can store is a session id. When user logs in the application, the application generates a session id for him/her, which will stay valid for two days. In every request that you make to the application, you add the session id as an HTTP header.
You can store the session id and the datetime it was issued in the preferences. When the user needs to make a new request to the application and the session hasn't expired, you can read the stored value.
If you are not looking to integrate this into the browser, then have a go at this.
If you look at the HTTP protocol, you can see that cookies are sent by the client in plain text in the request. This means you should have your application deliver them every time your request a page. This is not valid for local-only cookies, but I don't think that you're interested in these. If you want to set cookies from the server side, you will have to adapt your application to parse the response and look for cookies. (also HTTP protocol)
For a better view of the raw data you need to send or receive, you can monitor your traffic using Wireshark or a similar tool and see how the request/response look like.
I am currently working on a web-service that I need to implement on iPhone and this is my first idea of doing it. I haven't got to implement this yet (my web service is still not done) so there's not much more I can tell you at the moment.
Edit:
A useful page about this might be the Wikipedia HTTP Cookie page located here.
As Reno said, try to avoid storing the password in the cookie. Instead you should let the server generate a sessionID when logged in and let this ID expire on the Server after two days. SO you can login with the username and the sessionID you generated with logging in once.
I you want, you can store that sessionID in the cookie.