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.
Related
I am using IdentityServer4 version 3.1.4 with .NET Core 3.1 hosted on Internet Information Service 10.
Everything worked fine until the latest update for Edge, Chrome, and other browsers.
Now IdentityServer4 only redirects to client page after user login when I am using Firefox. Edge, Chrome, or others, return 302 code and go back to the IdentityServer4 user login page.
I read that it was due to the new cookie policy that Edge and Chrome enforce in their latest update.
I tried many solutions without success:
Set level of security headers
Enable Cors ...
Has anyone had the same problem? Did you manage to fix it?
Any idea is welcome
Please excuse my poor English
Do make sure you have set the SameSite cookie attributes to the correct values. Otherwise the cookies might be lost in the interaction between the client and IdentityServer. They should usually be set correctly in the code.
Do use a tool like Fiddler and inspect the requests to see if you loose any of the cookies on the way.
see this link about samesite
Instagram API requires redirect uris to have an SSL certificate (HTTPS connection).
I use Instagram API for my mobile app, and OAuth response should first invoke procedure in the app.
I am able to create a server to catch this call locally (on 127.0.0.1), but for the certificate, I can only create a self-signed one. The problem is that the browsers don't trust it and initially warn the user about the potential hazards, which is unacceptable for the user experience.
I saw a few similar questions on Stackoverflow, but unfortunately, I couldn't understand if they solve my issue.
How to avoid this warning?
Basically, even if they warns about https you can use api's. I had the same issue but I just tried to run the application on https port instead of http on localhost and it worked. So, Answer is you just need to run your application on https.
I have a solution for my specific case; I use Flutter for the mobile application. But overall you can find something similar for other cases as well.
Initially, I was launching the Instagram authorization window with url_launcher package. Basically, for iOS it launches the url in-app, but in a Safari Web View. In this way I am unable to control the flow in this web view. So, what I wanted to do is to catch a request to 127.0.0.1 when authorization is completed by running a local server in the app. It does work but throws a warning about security hazard due to a self-signed certificate, since Instagram requires https being used and 127.0.0.1 cannot have a trusted certificate.
Instead, now I launch the Instagram authorization window in-app with custom WebView using webview_flutter. It provides more flexibility, but most importantly I can track navigation. So now, Instagram redirects my user to the non-existing page on my website, which has a trusted certificate (but it doesn't really matter), but the aforementioned WebView can detect this redirect, parse the URL to retrieve the wanted code and prevent actual redirection by closing this web view. So, eventually, I get the wanted code in the app, so I can send it to my backend with extra user id reference.
So, basically, the workflow looks like this:
User clicks a button in the app to connect Instagram account;
The app launches a custom web view and opens Instagram authorization page;
After authorization, Instagram redirects the user to a dummy URL with the wanted code as a query parameter;
The custom web view detects this redirection;
Retrieves the code from the URL;
Closes web view (returns to the main app screen).
I can see that when I issue an xhr from my chrome app that it sends some cookies, and these cookies are kept track of in the app. Servers sending set-cookie headers are updating them correctly. I need to read a cookie though, and I tried using the "cookies" permission but chrome yelled at me... Is there another api I can use?
edit: I am using the new packaged apps.
Cookies is apparently a dark area of Chrome Packaged Apps.
With Extensions, the extension shares the cookie jar with normal browsing activities. For Packaged Apps, each app has a separate jar.
The current behaviour seems to be that XHR requests to sites specified in the manifest in the permissions section do set cookies in this jar but there is no way how to get rid of them, except reinstalling the app. There is no API for Packaged Apps to manage cookies and their cookies do not show in Developer tools or about://settings/cookies page.
the crbugs include
https://code.google.com/p/chromium/issues/detail?id=70391
https://code.google.com/p/chromium/issues/detail?id=152758
https://code.google.com/p/chromium/issues/detail?id=157474
and these two issues filled in response to this SO question
https://code.google.com/p/chromium/issues/detail?id=236585
https://code.google.com/p/chromium/issues/detail?id=335934
I had a similar issue where security restrictions on XHR in a packaged app with chrome.socket api permission seemed overbearing. See Setting "unsafe" headers in packaged app XHR
I ended up creating a "shim" xhr object for my use case, though it doesn't handle e.g. chunked encoding. You might find it useful: https://github.com/kzahel/jstorrent/blob/fresh/js/chromesocketxhr.js
I ended up filing a bug on crbug: https://code.google.com/p/chromium/issues/detail?id=335934
I have an application on Facebook which has two pages, index.php and admin.php.
On Chrome on my Mac, when I open the application it shows index.php without errors, but when I try to visit admin.php it fails to recognize the login, i.e. when I call /me I get such an error "An active access token must be used to query information about the current user."
It works:
using FireFox with the same account on the same computer
on other computers with other accounts, both Macs and Windows using Chrome
I've emptied the cache and cleared the Facebook cookies to no avail, I even tried in "incognito mode". I'm completely clueless: what could ever cause such a localized problem?
Check that Chrome isn't blocking third party cookies - if so it may be blocking the cookie the Facebook SDK uses to store session info
Try the incognito mode in chrome. It will disable most of your chrome plugins. If it fixes your issue, you can disable one after another here chrome://extensions/ in order to find out which one's the bad one.
The signed_request which I assume you are using to extract the information is only passed to the first page that the user visits within your application.
I would recommend creating your "admin" section dynamically (using Ajax calls perhaps) to add the extra UI for administrators.
Right now I am developing a Web-based Application, where the User has to login first.
When I open the Page by iPhone Safari, login and restart Safari, I am still logged in (Cookie & Session ID still set).
But when I add this Page with "Add to Home Screen", each Time i click the Icon for that page, I have to login again.
I did not find any information about that. What can I do so my users can set this page to their home screen
as icon and still don't have to login each time they open it?
A really simple approach could be to use a unique token in your Bookmark-URL which can serve you as a unique device identifier.
Example:
http://myWebApp.com/?token=randomId29238/1
The token can be generated at the server side at opening time of the application in Mobile Safari and before the user is prompted with the "Add to Home Screen" information.
The token can then be added to the URL using a quick redirect (…&token=randomToken) or a location hash (…#randomToken).
Whenever the Bookmark is now opened from the Home Screen, the token is sent to your server and you can identify the user's active session.
You may also use the token as a permanent session id, but I advise against that because of security concerns.
To allow future logout and login procedures, you can always assign the new sessions to the token.
The token will serve you as a unique device identifier whenever the user will re-open your link from his Home Screen.
There is an easier and, imo, more elegant solution than favo's.
At least under iOS 4.2.1, 5.1.1, 6.0 and 6.1 (I couldn't test other versions), if you extend the lifetime of your session cookie manually, Safari will hold on to the session cookie and even allow sharing of the session between the 'home screen installed' version of your web app and normal visits through Safari itself.
The trick is to do this:
// Start or resume session
session_start();
// Extend cookie life time by an amount of your liking
$cookieLifetime = 365 * 24 * 60 * 60; // A year in seconds
setcookie(session_name(),session_id(),time()+$cookieLifetime);
For a more elaborate discussion of this strategy you can take a look at my answer of this question:
Maintain PHP Session in web app on iPhone
I am going to expand a little further on Waldo Baggins' answer.
When I ran into this, I discovered the reason this was happening is that session cookies set on the server usually do not have an expiration value set. The default behavior in this case is for the browser to discard the cookie when the browser is closed / re-opened. Since the browser does not resend the cookie on re-opening, the server has no way of identifying the session, even if it hasn't expired on the server yet, and thus, your user is redirected back to the login page.
When the user is using your site in web app mode (icon added to home screen), iOS treats navigating to / from the app the same way a desktop computer would treat closing and reopening the browser, and loses the session when reopened.
So following Wilbo's suggestion and setting an expiration time for the cookie, iOS checks if the cookie has expired when the user navigates back to your app, and if it hasn't, re-sends the cookie, thus maintaining the session. The value of 1 year in Wilbo's answer is ridiculously long, you would typically want to set this to something like 8 or 24 hours, and ideally sync it with the session expiry timeout value you have set on the server.
Note that as a side effect, when your site is accessed from a desktop browser, and the user closes and re-opens the browser, the session would continue to persist and the user will still be logged in, which wouldn't have been the case previously (unless they were browsing privately). Your "Logout" feature would have to properly handle expiring this cookie.
For a Java webapp using web.xml version 3.0 or higher, the easiest way to do this is to modify <session-config> as follows:
<session-config>
<session-timeout>600</session-timeout> <!-- In minutes -->
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
<max-age>36000</max-age> <!-- In seconds -->
</cookie-config>
</session-config>
There are persistent key-value storage and database storage available for web apps. You can save your authentication data using localStorage object and use XMLHttpRequest to send it to the server.
Another option is saving your persistent data in a SQLite database, however this doesn’t seem to be a proper solution in your case.
Check out Apple’s Client-Side Storage and Offline Applications Programming Guide for details/examples.