I am building a Chrome Extension that loads data via jQuery from a background page, and relies on the user being logged in to the website to authenticate.
$.get('https://mydomain.com/myurl', function (data) {
// do something
});
Ie, a user logs on normally to https://mydomain.com, and some cookies are set by the server.
In the background page, get some data for that user at /myurl /myurl expects the authentication cookies to be present.
This works on a background page, but only if the the background script is reloaded after the user logs in. Additionally, once the user logs out and the cookie is deleted from the web page, the cookie is still there in the background page!
I'd expect that the cookies on the background page to stay in sync with the cookies on the website.
Not sure if this is a feature or a bug, or I am totally doing this wrong.
Turns out this was caused by using SignalR (websockets) in my background page. The websocket was opened before the cookie was set. So, I had to detect a change in the cookie, close the websocket, and then reopen it so that it would get the new cookie value.
Related
I am looking to replace a toolkit that does social auth through a seamless popup, where the entry point is a javascript function and there are javascript callbacks that you install that pass the results of the authentication back to you once everything has asynchronously been processed.
The socialbootstrap example shows how to perform posts to /api/auth/{provider} and this causes the browser to redirect to the login screen of the social provider and then back to a redirectUrl in the original app.
I would like to have this work in some kind of popup and the result be passed back to me as some kind of ajax result or a javascript success or failure handler.
Is this possible and if so do you know of any code examples that show this?
My understanding is that iframes are not a universally good way to do this as some social providers have iframe busters...
Thanks
If you only need to support Credentials i.e. UserName/Password Authentication you could do this via a HTML from in a Popup and ajax.
The https://httpbenchmarks.servicestack.net Live Demo shows an example of this when you click on Login with your email button or Sign In link (on the top right).
The Authentication/Login process is documented in detiail the repository, e.g it uses a modal bootstrap form and ss-utils bindForm to ajaxify the HTML Form and provide automatic form and validation binding.
On successful authentication, the success callback is fired where you can hide the modal form and run any other post-authentication scripts, e.g:
$("#form-login").bindForm({
success: function (r) {
$('#modalLogin').modal('hide');
localStorage["UserName"] = $("[name=UserName]").val();
$(document).trigger('signed-in');
}
});
Now that the Users Session is authenticated, every subsequent ajax request is sent in the context of the users authenticated session.
If you want to use OAuth then you would need to stick to full-page reloads since often the page will be redirected to the 3rd Party site where the user needs to explicitly allow authentication via your app.
I have a link on my web-page which automatically logs in through a generic username/password for the purposes of a demo, eg :
https://username:password#www.example.com
A dialog box shows up which says "You are now logging in as username. Is this correct?"
How can I remove this dialog to allow me to log into this web-page as cleanly as possible?
I've considered using JS to resolve the issue but there must be a simpler way?
Thanks
You are using http basic authentication which is a protocol that is a part of http. The username and password is sent to the web server and verified before your web page is loaded.
It is not the web page that creates this dialog, but your browser. It will be different for different browsers. Firefox creates a confirmation message when you provide the username and password in the address bar. Chrome will not create this confirmation message.
A javascript or any other kind of functionality in your web page would not be able to remove this message. The reason for this is that the message is created by the browser before the web page is actually loaded.
A previously working desktop application (until Friday of last week) was using the methods described here: http://instagram.com/developer/authentication/ to log a user in to Instagram. The application is a desktop application and it uses the IE browser component http://i.imgur.com/bCB5ZZh.png embedded in the program to show the user the Instagram login page and grab the auth token from the query string. But something has changed recently on the Instagram login page.
The easiest way to see what is happening is to watch this screen capture:
https://cloudup.com/cKQFpVcTv8E
Basically, there seems to be an error in History.js when opened in a HTML 4 browser like the IE browser component built into windows: http://i.imgur.com/HHJYidI.png
And if I load the full authorization URL ie: https://instagram.com/accounts/login/?next=%2Foauth%2Fauthorize%2F%3Fclient_id%3Dxxxxxxxxxxx%26redirect_uri%3Dhttp%3A%2F%2Fwww.xxxxx.com%26response_type%3Dtoken%26scope%3Dlikes%2Bcomments
... the browser component keeps redirecting and loading adding a "#" to the end of the query string.
I've found a few leads on SO:
History.js for HTML5 - Hack Needed to Not Break IE7
AND
history.js and header redirection
These seem to indicate that History.js needs to be modified to work with older browsers, but of course that would be something Instagram needs to do.
Again, this has been working for well over a year until late last week.
I have a great working chrome extension now.
It basically loops over a list of HTML of a web auction site, if a user has not paid for to have the image shown in the main list. A default image is shown.
My plugin use a jQuery Ajax request to load the auction page and find the main image to display as a thumbnail for any missing images. WORKS GREAT.
The plugin finds the correct image url and update the HTML Dom to the new image and sets a new width.
The issue is, that the auction site tracks all pages views and saves it to a "recently viewed" section of the site "users can see any auctions they have clicked on"
ISSUE
- My plugin uses ajax and the cookies are sent via the jQuery ajax request. I am pretty sure I cannot modify the cookies in this request so the auction site tracks the request and for any listing that has a missing image this listing is now shown in my "recently viewed" even though I have not actually navigated to it.
Can I remove cookies for ajax request (I dont think I can)
Can chrome remove the cookie (only for the ajax requests)
Could I get chrome to make the request (eg curl, with no cookie?)
Just for the curious.
Here is a page with missing images on this auction site
http://www.trademe.co.nz/Browse/SearchResults.aspx?searchType=all&searchString=toaster&type=Search&generalSearch_keypresses=9&generalSearch_suggested=0
Thanks for any input, John.
You can use the webRequest API to intercept and modify requests (including blanking headers). It cannot be used to modify requests which are created within the context of a Chrome extension though. If you want to use this API for cookie-blanking purposes, you have to load the page in a non-extension context. Either by creating a new tab, or use an off-screen tab (using the experimental offscreenTabs API.
Another option is to use the chrome.cookie API, and bind a onChanged event. Then, you can intercept cookie modifications, and revert the changes using chrome.cookies.set.
The last option is to create a new window+tab in Incognito mode. This method is not reliable, and should not be used:
The user can disallow access to the Incognito mode
The user could have navigated to the page in incognito mode, causing cookie fields to be populated.
It's disruptive: A new window is created.
Presumably this AJAX interaction is being run from a content script? Could you run it from the background page instead and pass the data to the content script? I belive the background page operates in a different context and shouldn't send the normal cookies.
after logging into GMail and clicking the back button on the browser the site doesn't gets back to user login screen? how is it done? Any pointers in java server side programming will be helpful. How to do it without java script.
They probably use HTTP cookies and server side sessions to track the user authentication state. Take a look at this article for more info about using cookies to persist login info.