How are authentication cookies read/stored when using cache-manifest?
I am using cache manifest to speed up a jquery-mobile app that has a browser baseline of Safari Mobile. I am using the multi-page template and within in one of the pages, I make an ajax request to my server for dynamic data.
The issue I am encountering is that when I cache the multi page template(index.html), it technically is not authenticated during subsequent reloads/views and when I make the ajax request, the server is not able to read an expected cookie value to bypass the ACL and thus allow the get request.
Thank you in advance for replies.
Related
Issue: appears to be that banno framework is "remembering" the urls. This is happening in a mobile browser when the user does not close the tab or browser. When the user opens the page, banno is remembering the url from last time and trying to load the same url.
What needs to happen is that banno needs to fully reload the page so that we can go retrieve a new url and log the user in again.
Could it be how they treat plugins when a browser is left open. A url that is loaded is not good forever.
Odds are good that the situation you're encountering is described in https://stackoverflow.com/a/71267143/6680761
Essential info from that link is:
Part of keeping state of the page is keeping authentication data. The OAuth flow used to initially authenticate the user is not intended to be used on every page refresh. It's expected that the embedded web application will keep its own authentication state. How this is done is usually very specific to the language and platform used for the embedded web application. However all strategies almost exclusively use a cookie which is destroyed when the application closes.
The Oauth callback URL with an authentication code should be redirected away from once the code is exchanged for an access token. From that point forward your app should be using its own authentication mechanism.
I am making an ASP.NET application and would like to be able for my file upload to allow attachments to be dragged straight from Gmail. The problem is that I cannot load the data from the links dragged in because of cross-origin rules.
There are 2 problems:
First, cross-origin rules prevent me from making requests to the gmail attachment server.
Second, even if I were to make the request with cross-origin, the cookies would not be included.
I am using Chrome and only interested in doing this on my own computers.
One option is I could make a Chrome extension which allows cross-origin requests but only from my website.
Another option would be for my locally hosted server to communicate with Chrome to make the request itself.
Which of these would be the best option and how would I do it?
When using the HTTP Authorization header in a web app it's necessary for the client to request any secured image resources via XHR because the element loads its src URL with no opportunity for the app to intercept the request and add the auth header. This is clearly designed for a cookie-based (forms) auth environment. To get around this limitation the HTML5 URL.createObjectURL() can be used to XHR the image as a blob and assign to the img src programmatically.
This is great, but I'd like to understand how caching works in this case. MDN says:
Each time you call createObjectURL(), a new object URL is created, even if you've already created one for the same object. Each of these must be released by calling URL.revokeObjectURL()...
The browser will certainly cache images by default, but what does that mean for multiple objectURLs to the same image? Does each new URL instance for the same underlying image resource mean duplicated memory or does that get cached too?
I have an MVC5 Azure web site which was working fine last night. Now it seems to be stuck in an infinite redirect loop when trying to login via chrome. It works fine from Edge and FireFox. It uses Azure AD for authentication. The redirects are back and forth from the main site to login.microsoftonline.com.
Sometimes, some bad tokens that AAD uses can get cached by the browser. They're used in place of the valid tokens, and not refreshed. Clearing the browser cache (Ctrl-Shift-Delete on Chrome) usually resolves this.
I experienced this issue with one of my Azure web apps which was serving traffic over http.
The solution for me was to disable the affinity cookie.
If I had an app where maintaining user session on 1 server was required I would have to re-enable the affinity cookie, but because that caused me (intermittent) problems I would also force all traffic to https as that seems to be a more successful set up to use with the Affinity cookie.
this link was really helpful and great background info:
https://azure.microsoft.com/en-us/blog/disabling-arrs-instance-affinity-in-windows-azure-web-sites/
My site is using HTTPS only.
I allow using BBCodes to show images. Users are placing images like "https://imagehoster.net/img.png" and the imagehoster is using a redirect so the browser loads it via HTTP "http://imagehoster.net/img.png". This makes the browser showing annoying mixed content warnings. Is there a way to prevent this?
Short: NO
Long:
the have no really web server listening to ssl.
in fact, there is only a firewall/proxy which sends a http locate to the browser.
You can't intercept that request. even if you could, where to redirect to?
they don't provide a ssl server, because it takes to much resources for encryption or it takes to much traffic, because proxy#s can't cache.
An idea to solve that problem:
detect those links, download them and store a copy on your server.
replace the link. maybe you need only to store a preview. if the click on it redirect to the original link on a new browser window.