I am trying to move the login session of Facebook from one device to another device. Both the devices use chrome browser. I tried using a cookie extension to export the cookies and then import the cookie on another device. The cookies in the logged-in device are:
In the destination device, after importing the cookie, when I open Facebook.com it asks for credentials as usual. Also, it replaces a few cookies and removes some (like presence).
My question is, is there anything facebook uses to stop transferring cookie sessions? How FB detect that it's a different device?
It's for leaning purposes to figure out the attacks and defenses in the cookies system.
I was able to get it to work by just creating c_user and xs cookies manually and copying the values in the other browser. I think I was doing something wrong while exporting or importing the whole cookie set.
Related
I deployed an app to both netlify(frontend) and heroku(backend) and it works fine on a laptop. But if I try to access it on my iphone, it does not store the intended cookies. If I switch off 'cross-site tracking' in my safari settings, I can then store the cookies. Is there any way around this? Thank you.
I see a serious design issue with how chrome apps are closed and how JSession or other http cookies are maintained.
In our current Chrome App, we are hitting a Restful site (Site B) to fetch some information after authentication. Site B returns the Http only JSESSIONID cookie in the response.
Now there is no way that I can simple logout or reload or close=>open the Chrome App and use a different authentication to access Site B, because Chrome App sends the same JSESSIONID again which is received during previous authentication.
More worse even if I pass authentication header with wrong userid/password, that is also allowed because as per the Java Spec JSessionId is given the preference over the authentication header.
There is no way in Chrome App that I can delete this Http only JSessionID or restrict the Ajax call (XHR request) to avoid sending the JSession Id. Even if you pass a wrong JSESSIONID with the URL, that does not work because as per the Java Spec, the JSESSIONID from the cookie is given precedence over the one in the URL.
Even If I considered all the above behaviour is per the Java Specs, then at least one would expect that the session cookies are automatically deleted when the Chrome App is close or reloaded. But it seems that the session cookies are not deleted because the corresponding chrome.exe instance is still running in the background. Once you close all the chrome browser instances and/or manually kill all the chrome instances from the Task Manager and reload the app, only then it works because now the session cookies are removed.
Can someone help me find out the chrome app APIs or settings which
1) remove the session cookies when the Chrome app is closed and reloaded.
2) kill the chrome.exe instance when the Chrome app is closed.
I am not looking for any kind of manual process.
Thanks in advance.
Kanchan
I'm afraid you're hitting something that's known to be missing from Chrome Apps platform.
Namely, there are no methods for managing cookies for XHRs originating from a Chrome App. Here's a related issue, see comment #11 specifically.
As mentioned in the issue, it's extremely clumsy but you could try and use a <webview> tag and make requests from within it. The cookies in it do not persist and can be manually cleared.
I have a query regarding to session maintain between application and web browser.
I'm developing an iPhone application and there is also one website (in wordpress) same for this application.
My question is , is it possible to show user login in mobile's web browser if he/she is login into application from same mobile device?
In short, I want to know where is this session stored? In application or in device? If it is in device then how can I check same for the web browser?
Cookies are stored per app, not per device. Safari has its own sandbox whereas each native app runs in its own sandbox, otherwise Safari's security model would be compromised.
In OS X, cookie storage is shared across all apps; in iOS, cookie storage is per-app. Reference: About the URL Loading System.
So for your scenario, this is how you should be able to make it work (I haven't tried it though):
In your mobile app, open website in Safari. Send a HTTP header to tell the web server that this hit is coming in from your native app
If you are already logged in via Safari, then your server will identify the user. Code your server to send back a redirect response (only in case when the request is from native app). This redirect response will contain a session cookie / auth_token with it. Also, the redirect location would use the iOS custom url scheme, e.g. myapp://mydashboard
In your native app, register the app as the handler of that custom url so that it can catch and handle the redirect appropriately
In subsequent requests from the native app, send the session cookie / auth_token
Hope it helps.
I have an application that may access authenticated content. I know that the webview can't handle authentication so I do some NSConnection magic to make it work (something similar to this)
The thing is that there is some content that can be accessible using this web view, but there is some other content that event after a sucessfull authentication, the web view is not able to load.
BUT.. if I enter the same url with mobile safari, enter the needed credentials and then I go back to my app, the WebView seems to load the content fine.
I tried reviewing the cookies before and after the auth in Safari is done using this code
[[NSHTTPCookieStorage sharedHTTPCookieStorage] cookies];
and the cookies are the same.
As far as I understand that code will retrieve the cookies my app generates and not the ones available in iOS, so apparently this is not the way to look for a hint...
Any ideas?
Recently, i've lurked for the same question over the internet, and the answer is "no" =(.
Objects of UIWebView class and Safari or other browsers live apart and are sandboxed.
Here is official position about cookies.
TO the best of my understanding, Cookies can not be sent with the first request from a Webview, but can be sent with subsequent requests to the same URL, if and only if, the first request was successful.
This causes problems with authentication services that require cookies to authenticate on the first request to the URL.
Possibly user credentials are stored via keychain api. Keychain is shared between apps, so stored login/pass in Safari can appear in your app UIWebView.Can you elaborate this as i also need this.
I have an iphone (jqtouch based) web app that uses cookies for authentication. The use flow is as follows :
user goes to the mobile landing page and is instructed to save the page as a bookmarklet on their home page.
they launch the bookmarklet to go to a login page to login and get a cookie.
the cookie works and they can navigate throughout the web site.
However this session cookie is not persistent. If they leave safari and then restart using the saved bookmarklet, the cookies set during their previous session are gone.
Just using safari (ie: launch safari directly rather than through the bookmarklet) to navigate the pages works fine (ie: start safari, go to url, do login, restart safari, go back to url).
I find that that the cookies that were active when the bookmarklet was created are persistent but any cookies set during the session when safari is accessed through the bookmarklet are not persistent.
I'm wondering if this is a safari/iphone issue and/or if there is any way around this. Many thanks for any insight you can provide.
K, for anyone encountering the same problem, i found a work around by making use of html5's localstorage. I just needed to use javascript to set the storage based on cookie values as the cookies were being set and to set the cookies from the storage values when the first page was loaded.
I have tried that in one of my applications. I have tried this in this way:
The user logs in and his cookie is set into the sharedHttpCookieStorage.
Check the cookie against your URL, get its values and save it in your application's storage.
Next time user wants to use your application, check if there is any cookie values in your storage. If Yes then create a cookie with those values else get him to log in again.
Make sure to clear the cookie values when the user logs out or the cookie expiration date reaches.
I know it sounds difficult but infact is really easy. All you have to go through is Apple's documentation on NSHTTPCookie.