I'm new to chrome extensions but I can't seem to understand what value the identity.launchWebAuthFlow adds over windows.create. I'm trying to use Oauth from an external provider. There doesn't appear to be any automatic persistence of an identity token as part of that flow. Also other browsers do not (yet?) support the identity.launchWebAuthFlow function. Both of which point to NOT using it vs a normal popup.
What am I overlooking?
chrome.identity.launchWebAuthFlow launches your authentication page in a window until it comes back to https://<app-id>.chromiumapp.org/*, and then the callback fires.
chrome.windows.create launches any URL and then fires the callback with the window object.
There's one significant advantage to chrome.identity.launchWebAuthFlow, from the docs:
Since some auth flows may immediately redirect to a result URL, launchWebAuthFlow hides its web view until the first navigation either redirects to the final URL, or finishes loading a page meant to be displayed.
This means that you can seamlessly sign in (if your auth supports it)
Related
Our scenario is the following:
We have an SPA that we package and send to multiple customers.
The customers hosts the SPA on an arbitrary domain like www.unknown.com/spa/anything-goes, or www.also-unknown.com/spa/really-anything-goes, etc.
The customer also opens the SPA in a popup window and injects a service to communicate back and fourth from the popup (the SPA) and the main window.
The SPA uses our own API service, lets call it www.backend.com, as a backend.
The SPA also uses the service that is injected into the popup window by the opener (the customer website), meaning the main popup (where the SPA is loaded) window can't directly redirect to a common login page, because that will interrupt the connection to the injected service, and we can't modify the customer code to make it more robust).
We want to let the user of the SPA authenticate against our backend (www.backend.com) using SSO (their Microsoft credentials)
For any given (fixed) domain, we can make this work by approving the exact domain as an allowed Redirect URI in AzureAd, and just using the MSAL in the SPA.
But how would you go about using SSO when you don't know ahead of time which Redirect URIs to add in AzureAd?
We can't re-direct the SPA to a common login page (cleared in AzureAd), because that would break the connection to the injected service.
The msal-browser library has an option to use a popup window instead of a redirect directly in the SPA window, but this option also needs a pre-approved Redirect URI.
I'm thinking we may need to implement custom logic to let our SPA open a popup window that navigates to a page we can pre-approve as a Redirect URI, that itself has the MSAL library and does the SSO login and communicates the result back to our SPA. But before I attempt a custom solution like that, I wonder if maybe I'm missing something.
Is there a more standard, less "hacky", solution that I have missed?
We would appreciate any input, thanks!
We eventually went with the solution I hinted at in the question:
Publish a simple page including the MSAL library on a "central" location that we can pre-approve in AzureAD. Let's call that the Central SSO-page (CSSO).
Let each SPA, running on what ever domain they want, open a popup with the CSSO. This runs the MSAL and completes the login.
CSSO has logic that, on login-completion, communicates back to the SPA, using window.postMessage("Some message", "https://somerandomdomain.com")
The SPA sets up a listener window.addEventListener("message", handleMessage(){..logic here}).
The drawbacks are, as far as I can tell, mostly that you need to make sure you are posting the message so that only the correct window can receive it.
Another drawback is that popups are often blocked, but in our case that is unlikely since our SPAs are running from domains where the main way of loading our SPAs is through a popup, so for the user to even see our SPA, popups must already be allowed. Still, some fallback logic is needed to open the popup manually with a click (which seems to circumvent the default block of popups).
I'd like to trigger the in-webpage refresh button programmatically for the purpose of applying labels to emails without making the user manually refresh the page or make some other page action in order to see the labels. Is this possible to do? All of the documentation I am finding is surrounding refresh tokens, which is obviously something different.
Thank you for your time.
There's no way to do that from the Gmail REST API (i.e. trigger refresh action in web browser viewing the gmail page). If you're running as a browser extension on the other hand, then sure.
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 want to restrict direct access to certain page in my application. Those pages can only be accessible if the user is redirected to those pages by the application.
All the redirections are done via ExternalContext#redirect(url) method.
User can use back and forward button, also can refresh the page by pressing F5 or via browser's refresh button. What I want is user cannot save, or bookmark URLs of some page, also cannot copy those redistricted URL and paste and go via address bar of the browser.
Followings are the cases:
Say, I have Page-A and Page-B.
Redirection is done to Page-B from Page-A.
User can go back to Page-A and can come again to Page-B by using browser's back and forward button.
User can refresh Page-B and he/she will stay in Page-B.
User CANNOT copy the URL of Page-B and access it later time (in new tab or by bookmarking).
Is it feasible? Any pointer would be very helpful to me.
I don't think you can do all that from JSF.
Your obvious alternative is to use Javascript.
I never herd a concept of disabling Bookmark option in Browser using Javascript. However you can always disable the address field if you open the page in new Window.
You can solve it with
JSF Navigation Handler - set a session attribute from some previous page and expire the value after some time with a timer. From the Handler impl check the value of the attribute and restrict access e.g. redirect to some other page in case the value is not present.
You can achieve similar behaviour with web frameworks. Enforcing controlled navigation is a basic feature in most WEB FXs e.g. JBoss Seam conversations or Spring Web Flow controlled navigation implementations.
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.