We have two administrative SPAs that can make easy use of the FusionAuth templated login / verify screens. This is useful as the screens automatically reflect our social logins as those are configured,
The third SPA is carefully designed and places the login fields on a dynamic splash page. I'm considering an attempt to html embed the FusionAuth login panel on our splash page but would need to strip away the nav bar and background container. I think this would be a global change to the FusionAuth UI web layout, forcing the use of embeds in all our apps.
We have FusionAuth running on a subdomain so an embed might not cause much CORS difficulty. Are there any other reasons that embedding the login panel directly from the FusionAuth server into our pages might not be a workable solution?
You can modify the FusionAuth login UI without impacting the administration UI. If you go to Settings -> System -> UI, you will see that the Login UI templates can all be modified.
If you have different login UI elements for different Applications, you can use the variable client_id in the templates to control the layout. This is the OAuth client_id that for the FusionAuth Application. These templates are FreeMarker, so a conditional statement might look like this:
[#if client_id == 'ee31103f-2fc1-4bb5-ba95-ac543693503e']
Embeddable HTML/CSS goes here
[#else]
Standard HTML/CSS goes here
[/#if]
That being said, the OAuth login UI of FusionAuth might not be easily embeddable in your third SPA depending on if you are using an iframe or AJAX. It is still probably a better idea to skin the login UI to match your UI instead and leverage the OAuth login workflow if possible.
The other solution is to use your own login page and then call the FusionAuth APIs to authenticate the user.
We have been exploring adding an embeddable login system. If you want to open a feature request for this, you can add it on our Github Issue tracker here: https://github.com/FusionAuth/fusionauth-issues
Related
We have a native app and an Alexa skill. You can't use the Alexa skill without the app and you need to have your app account first. Some users are creating accounts with the Alexa skill that aren't linked with their app accounts.
We can disable self-registration and the sign-up link goes away in the hosted UI, but it also prevents account creation from the application using Amplify.
I looked at the hosted UI customization CSS to see if I could style that link to hide it, but the CSS customizations don't seem to address that link specifically. I'd like to avoid reinventing the entire auth wheel just to get rid of that one link.
Is there any way to disable the "sign up" link in the Cognito hosted UI without disabling self-registration?
Thanks!
You have 2 options as far as I know.
Use custom lambda trigger on signup to reject calls made from your hosted UI
Use your own login page instead of hosted UI.
Unfortunately, there is no way to modify the contents of the UI. You can only change the CSS and add a logo.
The first method is easier but is a bad implementation because you are confusing your users with a button to register but then rejecting all their attempts. Second method is the best way to achieve what you want.
Another method is to use the adminCreateUser function, give it a temporary password and suppress email sending of the temporary password. Then do adminSetUserPassword to give the user the desired permanent password.
This technique seems to work properly when the "Enable signup" feature is disabled.
I'm enjoying developing cross-browser web extensions, the main target being Chrome, so much that I started to think to develop one for my company. I find a chrome extension quite a cheap and efficient way to deploy internal apps. The main purpose is to host a couple of dynamic dashboards that fetch data from various APIs by using cross-domain ajax in background scripts. I finalized the app and I was also able to implement the authentication via chrome.identity and Azure AD.
However, I am struggling to find a safe way to customise the content.
I mean, when the extension is installed it requires to login to azure via the chrome.identity flow. Then I get a token that I use to query ms graph and get the user ID, name, email and basic info.
Until I get this information I want the browser action (popup) to be unavailable to the user as well as any other extension pages. After a successful login I would like to show the content on the pop up and to let the user access the pages, but here I want to customize the experience.
I know how to use the user id retrieved from the api call to customize the extension, but I think it is not safe because all the code is in the client.
If I code something like
if (user === logged) show something
it will be damn easy for a malicious user to look at the code and bypass it, or even to impersonate another user. And chrome extension cannot be obfuscated.
Any help?
Thanks
I have multiple ember apps, but just one of them has the login page. I want to authenticate all of them with this unique page. How can I redirect other apps to an external login page using ember-simple-auth and redirect to the corresponding app after the authentication?
You need to write custom authenticator. In it's authenticate method I suggest to not redirect, but open a child window with login page. And that login page should be able to communicate with your ember app in some way (window.postMessage for example) in order to give your app auth token. Authenticator must wait until it receive answer (promise and timer will help with waiting). I used such method with google's oauth in node-webkit application (my authenticator opens google's oauth page where user prompted to give my app an access). I don't want to share a code because its too big, complex and have code specific to nw.js but I hope my answer will help. I used code of oauth2 authenticator to develop my own, it helped me a lot.
Currently we have a Hybrid solution where we show a web form in our Movilizer screen. This solution does not open a new browser window, but the form is shown in the movlizer screen.
This form need to be logged in with our credentials (using our login page).
Now we have a new requirement that on referring to the form, instead of our login screen, it will be redirected to a third party authentication login. Once the user is authenticated by this third party authentication, it will be redirected to the our web form.
How can we achieve this?
This must be solved first in the HTML world. Once the auth in HTML is completed (positive or negative), you can use the Movilizer specific Cordova JScript functions to provide the result to Movilizer, so the MEL logic in your Movelets can operate with it.
Movilizer runs HTML through lightweight html engines / browser components out of the frameworks of that specific platform. In other words, Movilizer clients use functionality that the native frameworks provide ... Movilizer does not have impact on how HTML itself is processed in there. Regarding the typical problems different browsers on different platforms normally bring, this means you have to carefully test the HTML part of this process on a multitude of platforms and devices.
I am adding the ability for a user to link their foursquare account with their account on my website. Foursquare's oauth account authorization takes the user to foursquare's website, and after authorizing my website it redirects the user back to a url.
I want to avoid breaking the user's context on my website when they decide to add foursquare functionality to their account, so I'm planning on doing foursquare's account authorization in a new window using
var foursquare_popup = window.open("foursquare_url_to_authenticate_user");
and redirecting the popup to a static success page once the authorization has been completed.
I've seen oauth popups done in a couple places like Wired's tweet button.
Is this a good way to handle oauth with things like twitter/facebook/foursquare?
i would recommend against opening a popup window as part of the oauth signin process, purely because some browsers do not support popup windows - particularly browsers on mobile phones. also, the browser may support popups but the user may have a popup blocker turned on.
a better way would be to redirect the user from your website to the service provider all in the same window.
i am currently working on a way to do this with an invisible iframe on the page of my website. this way, if the user is already logged in to the service provider then they would not need to be directed away from my website. however, i am half way through this functionality so i cannot confirm that it will work yet.
You can specify display=webpopup if you want to use a pop-up window (see https://developer.foursquare.com/overview/auth#display).
Also, you can specify additional parameters in your callback URL, which will be preserved by the oauth flow. So if you passed "&state=settings/accounts" or something as parameter of your redirect_uri, you can parse it out upon success and resume your session with the user appropriately.