How do we test SPAs which have Azure AD based authentication? When user opens the app, user is first sent to login.microsoftonline.com and on entering the user email the page redirects back to application home page. In this scenario, how do we automate using Playwright?
Could you elaborate a bit more on what you're looking for? The flow should look like fill credentials, login, wait for your logged_in condition, whether that be a cookie that gets set or a redirect (a simple redirect would be easy to handle).
For example:
await Promise.all([
page.fill('input[name="loginfmt"]', credentials.username),
page.waitForURL(HOMEPAGE_URL),
]);
See page.waitForURL.
Then you can do stuff like extract the user's session for reuse to avoid having to login again if that's desirable:
const session = await context.storageState();
// Store them somewhere?
await cache.setCredentials(session, cacheKey);
See browserContext.storageState.
Related
I'm using NextAuth's EmailProvider and FaunaAdapter with a FaunaDB instance to authenticate users in my NextJS application. I'm going down the "passwordless" route with this site, and the magic links are setup nicely after finishing the bulk of this tutorial.
There are some changes I've made to it, however, as I don't want a Sign Up page, and instead want only whitelisted emails that exist in my DB to be sent links to authenticate. I've done this by hijacking the signIn callback like so:
async signIn ({ user, account, profile, email, credentials }) {
// As "signIn" gets called twice when using magic links (once for sending and once for authenticating),
// we need to check here if this is a request for a magic link, as opposed to authenticating a token.
if (email.verificationRequest) {
// This is a helper function which does a lookup for the email in the "accounts"
// table of my Fauna DB.
return checkUserEmailExistsInAccounts(account.userId)
}
return true
}
This works nicely, but I wonder if it could be improved. I want any page that is behind the authentication wall to effectively have a session or JWT token that describes the user in more detail. If, say, I want the user name to be added to the session data, I then need to somehow modify the session or jwt callbacks to add this data. But that will involve yet another call to the database, where I have already made a perfectly useful call in the signIn process. Whats more, these callbacks are made frequently - whereas the signIn callback is only made a couple of times during the authentication process.
To summarise: how can I leverage a magic link sign-in system with NextAuth where I look up allowed emails from a pre-existing Fauna accounts collection, furnish a user object with the account data and have the account data become available to every page without needing further lookups when already-authenticated?
Edit: Just a note to say that when I first started playing with the library, I was surprised that simply putting the data into my accounts collection in Fauna DB didn't somehow magically make it appear in the session info. Perhaps I am not using the Fauna Adapter correctly, and this is actually the better way to go?
I have a web app and I am using firebase authentication to login/signup our users.
In the past I have used Passport for login in my app which works but you have to maintain your own database and security blah blah... but I can control when my user can visit a page after logging via Passport using middleware like this -
// isAuthentcated is my middleware on server side.
app.get('/home', isAuthenticated,(req,res)=>{
res.render('home');
});
How can I do the same using firebase because there isn't any mechanism to do that. I have read different answers on stackoverflow and most of the pople are suggesting something like below which obviously isn't secure. Anybody can just type home.html and get to the page.
firebase.auth().onAuthStateChanged(user => {
if(user) {
window.location = 'home.html'; //After successful login, user will be redirected to home.html
}
});
Although, I have thought of using firebase-admin sdk token verification and try to follow the suggestion here but I don't know how it can be useful to do that on server side. Do you guys have any suggestions? How do you redirect user to a new page. An ajax post/get request from a client to a route '/home' with a header containing 'Bearer token' just validate the token but doesn't redirect user because it is a ajax call which is meant for updating a portion of a page.
Now, the question really is, Is it even possible to do that with firebase authentication?
If you host your site on App Engine you can send the ID token of the client with the request for the HTML. This could take the form of a cookie, a parameter, or whatever you choose to securely transfer the token from client to server.
Then the server can use the Firebase Admin SDK to verify the ID token, and use whatever logic you need to determine whether the request is authorized.
With Auth0, Using the SPA example, After performing a login, I see that that the user stays logged in on the next session without having to re-enter it’s credentials.
Two questions:
On the client side, I see that a cookie is created that enables the user to stay logged in without having to open the login screen. It looks like the default expiration time is 22 hours. Is there any way to extend this time frame?
Even if the the cookie expires, I see that the login screen does not require the user to re-enter it’s credentials and sends the token automatically. How long is the device authenticated without having to re-enter the user credentials? And can this be modified?
Thanks!
let auth0 = null;
const isAuthenticated = await auth0.isAuthenticated();
if(!isAuthenticated)
{
console.log('Not Authenticated, redirecting to login page');
await auth0.loginWithRedirect({
redirect_uri: window.location.href
});
}
else
{
console.log('Authenticated');
}
Here is the answer from Auth0 community form (Silent authentication was needed):
https://community.auth0.com/t/how-long-does-the-user-stay-logged-in-and-it-can-be-extended/38871
I have been using firebase chat and firepad for real time functionality in My Web Application which has multiple pages like a forum.
I started using the Firebase SimpleLogin too.I am able to login as a user and get the auth object which has the uid,id etc info.
1)Now if the user traverses to another page(i.e a new url(same application) is loaded ),does the authentication persist ? Ofcourse as we are manually doing the authentication by calling ref.login(),how can we know if the user is logged in when the second page is loaded.Will firebase store any cookie in user's browser or local storage ?
2)If the user is authenticated through firebase and now for for any request to my backend server for a new page ,how will I know that the user is authenticated.Should I be manually handling this by inserting some cookie in the browser or a hidden form field once firebase login happens ?
3)Is firebase Authentication suitable for multi page web application where the html pages and content are served from a back server other than firebase.?
I have checked the below question too.
Firebase JWT Authentication, Continually Send Token?
As long as browser cookies and local storage are both local storage is available on the browser, Firebase Simple Login sessions will be persisted across page refreshes on the same domain. Simply reinstantiate the Firebase Simple Login client via new FirebaseSimpleLogin(ref, function(error, user) { ... }) to restore a persisted session, if one is available.
Using this approach, your callback will automatically be invoked with the login state of the user. Note that you do not need to call .login(...) again to pick up a session, as calling .login(...) will always try to create a new session.
Once the user is authenticated, you can begin writing Firebase Security Rules, making use of the auth variable, which is non-null for any authenticated user, and will contain useful user information (such as user ids) when using Firebase Simple Login. See the 'After Authenticating' section of any Simple Login auth. provider page to see the exact payload.
In the event that you already have an authentication system you'd like to integrate with Firebase, or Simple Login is not sufficient for your needs, you can always generate Custom Tokens with your own custom data. These tokens can contain any arbitrary JSON payload of your choosing, which will be available in your Firebase security rules under the auth variable.
See the Firebase Security Quickstart for more information.
Is there a way to pass a value back to a relying party after login? e.g. on the querystring?
Background:
What we want to do is inform the relying party what action the user took, e.g. sign in or register, so that the relying party can display the appropriate confirmation message to the user. Because the relying party might link to a Sign Up page, but then instead of signing up the user signs in, so the relying party shouldn't display a "thanks for joining us" notification panel.
I tried adding &lastaction=signup to the returnUrl but that gets lost when the form is posted through Azure ACS.
Next attempt was to try to add lastaction to the wreply, like so:
WSFederationMessage message;
WSFederationMessage.TryCreateFromUri(uri, out message);
var signinMessage = wsFederationMessage as SignInRequestMessage;
if (signinMessage != null)
{
signinMessage.Reply += "?lastaction=hello";
...
In Fiddler I can see that the next POST to ACS posts to https://xxxxx.accesscontrol.windows.net/v2/wsfederation?lastaction=hello
But the lastaction is not passed on to my relying party.
We had a related problem: we wanted to let the RP know which authentication methods the user used when signing in. We solved this by creating a new "system" claim with our namespace, and put the information in there.
In our TokenService implementation, in the AddSecurityClaims method:
claimsIdentity.AddClaim(
new Claim(
String.Format("{0}/{1}", WellKnownConfiguration.TokenService.ClaimsNamespace,
ClaimsAuthenticationMethods), ((int) userAuthenticationMethods)));
Update
You mentioned you thought about using cookies. In that case, I would do the following. I would implement setting a cookie (e.g. when registration page) and then create one more "action" that would return the value of that cookie. When the app gets the POST request with the credentials, you'd perform a redirect (immediately) to that relaying action with a return url. That action would then append the value of the cookie and call the original RP, but a custom action, that would then properly display the view.
Think of it as a cookie proxy. To summarize, the process is as follows:
User hits the RP, action requires authentication
The RP redirects the user to the STS as per WS-Federation
STS issues a token, and also adds a cookie to its own domain
RP gets the authenticated user, redirects to STS Cookie Reader
STS redirects to RP's second screen that can handle the login properly
All in all, one more hop, but like I said, it's probably fast enough for the user to not notice and/or care.