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
})
Related
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!
In a spring security application i am navigating to the login page and entering my credentials and getting logged in.Now again if i open a new tab in the same browser and navigate to the login url it shows me the login page.If I enter another users credentials and login my previous Jsession ID(ie: the one created in the previous tab) is getting overridden with the new jsession id.Upon refreshing the previous tab the session is overridden.
I want to implement that if a user is logged in already in the application, upon navigating to the url again in another tab on the same browser the homepage of the application should open.
Please advise as how I can accomplish that?
Since the server uses the cookie to map to the current session, you'd have to control how the browser sends cookies. Every time a request is sent to a website from a new tab, most browsers will send all the cookies it has for that domain. Since your server received the same session cookie, it will treat this request as being in the same session. There's no way it can tell the difference.
Therefore, as far as cookie-based web sessions go at least, you probably won't be able to force the creation of a new session upon opening a new tab.
We have a custom WebDAV solution using the IT Hit WebDAV server component. For authentication we are using an Identity Server 4 implementation. The authentication flow, from the user's perspective, is roughly as follows:
Users clicks the link to the WebDAV document in the application.
Office (in most of our test cases, Word) is opened.
If this is the first time the user has opened a document (or the cookie has expired) a login dialogue is shown.
The user enters their username and password, hits the login button and if successful the document is opened.
Behind the scenes the flow is similar to the following:
A HEAD request is made to the parent folder of the document e.g. https://webdav.example.com/documents/
The response to this request contains the headers necessary for Office to show the login dialogue. X-FORMS_BASED_AUTH_REQUIRED etc.
Office follows the URL from the value of the X-FORMS_BASED_AUTH_REQUIRED header. e.g. https://identityserver.example.com/connect/authorize?client_id=WebDAV&response_type=code+id_token+token...
This returns a 302 response with a location similar to: https://identityserver.example.com/account/login?returnUrl=%2Fconnect%2Fauthorize%2Fcallback%3Fclient_id%3DWebDAV%26response_type%3Dcode%2520id_token%2520token...
Office opens this URL in the dialogue. Once the user enters their credentials and hits login a POST request is made to the login form, this returns a 302 with the location of the Identity Server callback URL e.g. https://identityserver.example.com/connect/authorize/callback?client_id=WebDAV&response_type=code%20id_token%20token...
A GET request is made to this URL which then POSTs the Identity Server info (tokens) to the configured client callback URL e.g. https://webdav.example.com/account/callback.
This is a custom endpoint that stores the Identity Server access token in a cookie (so that Office can use the cookie) and then responds with a 302 with the location of https://webdav.example.com/account/success. This URL is the same one configured in X-FORMS_BASED_AUTH_RETURN_URL header.
Ona Windows client this all works fine. However on a Mac (Mac OS Sierra 10.12.6) and using Office 2016 (16.11.1 (180319)) we see that the 302 response is returned from the https://webdav.example.com/account/callback URL but it's never followed, there's no GET request made to https://webdav.example.com/account/success.
In addition, there are further WebDAV requests made and stepping through the code we can see that the cookie never seems to be set on the Mac despite the code to do that being executed without error.
So, what's going on?
Thanks,
Stuart.
Using the new outlook rest api's to import contacts from outlook/hotmail email accounts. There is a minor glitch though, once the user clicks the import contacts button and the initial MS auth dialog pops up (url - login.microsoftonline.com), as soon as the user finishes entering their email address, the page suddenly redirects to login.live.com.
This is bad because:
this happens without any warning (user could be in middle of entering their password for example)
what's the point of using the new api's if the auth is still being handled by the old live connect api endpoint.
Would like to know if there is anyway to prevent this redirect from happening?
Maybe I am missing some param which needs to passed in to the initial auth url?
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!