For our application's e2e tests we are using Cypress (v10.7.0), but there is a strange behavior that we have encountered since we switched to version 10.
We have the following test:
it('should log out on clicking logout menu item', () => {
# login user
cy.login();
# logout user
cy.get(options).click();
cy.get(logoutButton).should('be.visible').click();
# verify that the user has been successfully logged out
cy.url().should('contain', ssoUrl);
cy.get(emailInputField).should('be.visible');
cy.get(passwordInputField).should('be.visible');
cy.get(options).should('not.exist');
});
The issue here is that when we click on the logout button, the application basically redirects to the OIDC url (we have an SSO login which is later verified using OpenID Connect) and then the application proceeds to the Dashboard again, instead of redirecting to the login page.
This however, does not happen if we open the DevTools >> Application tab (we are using both Electron and Chrome) and observe the "sessionStorage" changes during the test execution.
Does anyone have any idea in what could be happening?
Related
We have witnessed a scenario, where it is required to get the user authenticated by Microsoft and then request a callback url.
Login url
We have successfully mitigated the new login prompt window and trying to open Authentication url(got via new window object).
But it is now being visited as the url is continuously redirecting through multiple domains.
We have tried to use origin manually via this process, but when it will redirect to another (unknown)URL, the test will lead to a blank page.
Is it possible to visit an unknown URL and complete the authentication.
cy.origin('https://login.microsoftonline.com/', () => {
/// get email field and try to type
})
We have an issue with a asp.net core 3.1 MVC application. The application is using the built in asp.net Identity feature. The application is working well for existing users. If you hit any [Authorized] route, you are redirected to the login page as expected.
However, rather than have a registration process in our app, for new users, we onboard them via Stripe Checkout. Upon successful payment, stripe redirects to a specific route in our application /conversion/success/{sessionid} where sessionid is the Stripe session. This action is marked as [AllowAnonymous].
We then pull the necessary customer details from Stripe, create a user in our repository via UserManager<T>. We then call SignInManager<T>.SignInAsync() to sign in the new user, before redirecting the new user to the [Authorized] home page.
This process works perfectly when running locally on our test machines. Also, when running on our production server (Azure App Service) it also works perfectly when we hit the route manually through the browser.
However, when we actually run the process through Stripe, complete a payment and let Stripe redirect the customer, we get a strange behaviour.
The conversion route is hit, the user record is created, the sign in process completes but upon redirection to home page, the authentication middleware takes over, says it's not authenticated and redirects to the login page.
Just to compound matters further, if you then simply type in the home page route in the browser, the user is in fact logged in exactly as expected and the application works perfectly.
Using Fiddler to intercept the calls and look at headers, etc. we can't see why there would be a different behaviour when coming from Stripe as opposed to typing directly. We've even tried redirecting from a different website to our registration process and that works as expected too.
Any idea why we are seeing this behaviour?
---- Update ---
If, rather than redirect to home page at the end of the onboarding process, we simply show a simple View with an anchor link to home page, the user can then go to home page as expected.
Is it possible that you're rendering the page before authentication has been completed? Since UserManager uses a cookie to establish the user's session, authentication needs to complete before any response headers or body is set so that the Set-Cookie header can be sent in the response.
Based on what you described it sounds like the user is hitting the homepage after the redirect without having the authentication cookie. Where I'd start debugging this is by using your web inspector with "Preserve log" turned on and going through the Stripe Checkout process. Then, inspect the headers sent to the browser when you land on the redirect page & make sure the authentication cookie is set.
Between requests to Stripe and SignInAsync it seems possible that there might be a missing await, so the redirect is happening before the authentication context is updated. Hard to say more without seeing your code!
My application is using Google sign-in but signout of which is not working properly. It is redirecting the user to an intermediate page with title "Redirect Notice". This is happening since last few weeks.
Application logout URL:
https://www.google.com/accounts/Logout?continue=https://appengine.google.com/_ah/logout?continue=http://example.com
I am trying to redirect the user back to my application (with URL: http://example.com)
but it is showing an intermediate page:
How can I remove this intermediate page and redirect user back to http://example.com?
I am trying to record a test script with JMeter for an internal website hosted on company intranet. I can record only till navigation of the login page, submitting username/password, and click on login button. The login page reloads all the time. Nothing else happens.
Steps to reproduce ->
1) I started the JMTeter HTTP Test script recorder
2) I changed the browser settings to point it to the proxy.
3) Navigated to login page, keyed in username/password, and clicked login
4) The login page reloads, nothing else happens.
I tried it on all the browser. It's same everywhere. I recorded testes on gmail and facebook successfully. I did not face any issue there for navigation. Please help me. Is it an issue with the server where the site is hosted?
What kind of login authentication that you used in your internal website? Is it the same authentication as gmail or facebook (using login form, then compare it to database)? Or is it Active Directory User (windows account) authentication (usually, there is browser popup to enter username and password).
You can try this:
Start the JMTeter HTTP Test script recorder
changed the browser settings to point it to the proxy
Navigate to login page, keyed in username/password, and clicked login. From this point, you will have sampler for login step
changed the browser settings to not using JMeter proxy
Navigate to login page, keyed in username/password, and clicked login. It should be working
changed the browser settings to point it to the proxy again
Do the rest recording normally to get the rest scenarios.
I hope that will help you.
I am using Ionic to build a login system on top of Codeigniter/Ion_Auth/codeigniter-restclient and when I try to login from "ionic server" the login works but the next api request to the logged_in() method returns false.
The same thing works properly when I point the browser to the www folder.
So here is the problem step by step:
run ionic serve
you see the login form (http://localhost:8100/#/app/login)
enter email and pass
the rest api returns "login successful"
$state.go('app.profile') works and redirects to http://localhost:8100/#/app/profile
REST get api/logged_in returns false and I redirect to the login page
If I do the same in a regular browser, step 1 becomes: open browser and go to http://localhost:8888/App/www/#/app/login, at step 6 REST get api/logged_in returns true and I don't get redirected to the login page, I stay on the profile page.
The code is the same. So my guess is that maybe ion_auth doesn't get the cookies it wants or the session is reseted. I am not sure at this point what the problem is. This is my first Ionic/App project so I might be missing something about the proper way to authenticate from a mobile app using code that works in browsers
Thank you
UPDATE:
It seems that when using the 'ionic server' window every request to the API triggers a new session. The new session is stored in the database and ion_auth tests the logged_in against that last one, which doesn't contain the login details.
you were taking about REST api and cookies and sessions. Cookies and sessions don't go with REST philosophy. Here is why.
Let me tell you how we accomplish this problem in our project. Basic way of knowing which user is requesting and if it has the access rights is by the 'Authorization' header value. You can use Basic Authentication, Barer or any other.
We generally prefer token based authorisation system. When a login is successful, server sends a token. In ionic app, we save it using a factory called SessionService. So whenever user logs in, token is stored and is used for every request. But token would be lost if user closes the app. So we can store it in local storage. User can then be directly redirected to dashboard until user logs out.
app.factory("SessionService", function($window){
var user={};
if ($window.localStorage['user']!=undefined){
user=JSON.parse($window.localStorage['user']);
console.log(user);
}
return{
isLoggedIn:function(){
return !isEmpty(user);
},
logout:function(){
console.log("logout")
user={};
$window.localStorage.clear();
},
setUser:function(data){
user=data;
$window.localStorage['user']= JSON.stringify(user);
},
getUser:function(){
return user;
}
}
})
Now in every web request, you can call SessionService.getUser().token when setting value Authorization header.
UPDATE:
Despite using cookies is not recommended, you can use it in your application easily.
If you are sending request with CORS, angular doesn't sends cookies with request.
One of the way address this issue is to send withCredentials: true with every request:
$http({withCredentials: true, ...}).get(...)
Read further about this here.
Hope this helps!