Page reloads 3 or 4 times after log-in #151
Comments
|
I'm looking into the issue, and trying to reproduce it on my side. |
|
Appreciate any help. Thanks. Let me know if more details are needed. |
|
Did you take the latest version? I'm playing with the SinglePageApp-WebAPI-AngularJS-DotNet sample, and I could not reproduce the problem by trying: 1) set the require AD to true for the route you want to access, which is triggered by the first call to a protected endpoint via $http 2) click on log in and then do the same thing. If you could provide the detailed steps for reproducing, that will be great. |
|
I did take the latest version. Those are the repro steps. I'll go back to a clean copy of the ToDo Spa App sample and see if I can reproduce it as well. |
|
Where is the repro steps? Did you forget to attach? |
|
Sorry The ones that you listed are the basic repro steps: 1) Setup the app. 2) log into the app then do something to trigger a AJAX request to a protected endpoint. |
|
I think I was able to repro the issue using the stock sample. Here are the specific repro steps I used.
In my actual app .config is invoked 3 times. With each invocation several API calls are repeated causing a long initial load time for the user. Let me know if you see the same behavior using the more specific repro steps. |
|
Thanks for the repro steps. I'll try to recreate on my side. |
|
For the sample, when clicking on ToGo List, it will call the acquireToken if no token stored in cache, and adal.js currently did a full redirect. This will cause .config to be invoked again. |
|
is aquireToken called before adal:loginSuccess is triggered or only when a call to a protected endpoint is invoked? I ask because I am only starting the ajax request when isAuthenticated is true or on adal:loginSuccess event. |
|
acquireToken is used to get token for a given resources, it could be trigger in different conditions. A call to a protected endpoint could trigger it. Actually, you could set requireADLogin to be true for the route you want to protect, and ADAL will start login and load the protect route. And then you can make your ajax request. |
|
I have all of the routes configured as requireADLogin = true except for the postLogoutRedirect location. |
|
Interesting. It looks like acquireToken is called multiple times for https://cloudmedIdentity.onmicrosoft.com/dataApi. Is this the most recent logs you have? In the latest version, we start to log out the request type. I just want to make sure you did take the latest version, I saw some similar loop before, and we make a fix to it. Another thing, could you set breakpoint on acquireToken in adal.js, and check when it's called? |
|
Thanks for the effort so far, we're really stuck on this one. I'll take the tip from github and repro the issue and capture new logs as well as set the breakpoint on aquireToken. |
|
I'm back at it after having to focus on some other priorities. I updated to 1.0.5 and reproduced the issue. I see the new logging messages regarding request type. I've also captured the call stack when aquireToken is called (3 times). Also update angular to the latest (1.4.4) Let me know if there is any other info I can gather or tests I can run to help pin this down. here is the stack trace: Here are the log messages: |
|
This could be related to you listen on the adal:successlogin. Have you already logged in or you directly go to the protected route? If you went to the protected route without the user logged in, adal will trigger the user logged in(this will cause the broadcast of adal:successlogin event), and then add tokens. Your app listens on the login event, and when it captures it, this could trigger another token request. |
|
All routes in this scenario are configured as protected routes. Using breakpoints I have verified that the successLogin event is only triggered once. I've tested it with that code removed and when redirected back from the login page $scope.userInfo.isAuthenticated is still false and a second or two later successLogin is triggered and $scope.userInfo.isAuthenticated is set to true. Regardless of how it is initiated the first API call to be made after adal:successLogin is fired the page reloads 3 times. I could supply you with a test account to repro the issue with if you'd be willing to take a look. |
|
I have the same issue. At first, I noticed that my API calls were occurring twice, as indicated by the OP. But, on further investigation, the entire app module is instantiated twice so basically, everything is done twice. |
|
I have the same issue as the users above, everything executes twice after the first log in. |
|
@weijjia any plans to dig into this? Or any other steps I could take to further troubleshoot this? |
|
Sorry for the delay. I'll get back to it this wee. |
|
Let me know if you want me to setup you up with an account to our app for a repro. |
|
I too have the same issue. Couldn't fix, any updates? Here is what I get. I get this error in all browsers (including MS EDGE) |
|
Just an FYI: This appears to be unaffected by 1.0.7 release. |
|
Did you try adding https://login.microsoftonline.com to your trusted sites? |
|
Hi, I wonder if this is related to #182 - for Firefox or #42 maybe! |
|
Facing the same issue. is there a known solution/work around? |
|
Hi this issue happening because of handle window hash. When this function is called it strips off Hash and sets window location which causes refresh again. I struggled a lot to workaround this issue. Also i am facing another strange issue and that too its happening only in IE,. It is AAD 6500: renew token failed due to app doesn't have permission to read user data. I really did not understand why this issue is coming during renew token. If permission is not there it should fail during login itself. Can anybody help us on this? |
|
Hi guys, same thing here.
@shekhardesigner, after having spent some hours for investigation of the issue, I wrote a small piece of code which fixed the situation for me: function fixAngularLocationBug(e) {
function isUserAuthenticated() {
const result = $rootScope.userInfo && $rootScope.userInfo.isAuthenticated;
return result;
}
function isLocationMailformed() {
const idToken = "id_token";
const result = $location.path().indexOf(idToken) > 0 && window.location.pathname.indexOf(idToken) < 0;
return result;
}
const authenticated = isUserAuthenticated();
const mailFormed = isLocationMailformed();
if (authenticated && mailFormed) {
e.preventDefault();
}
}
$rootScope.$on("$locationChangeStart", fixAngularLocationBug);The things happen there and causing the bug are the following:
|
|
@tushargupta51 Shoud that be included in 1.0.9 milestone as well? I think this is the most annoying bug in ADAL so far which kind of prevents from using the library in a more or less serious application. |
|
@PavelPikat You got it. |
|
Consider managing the loginInProgress value in the session storage (i.e. mark it with "in progress" before redirection, skip re-login if this is the value in the storage, and set it to "connected" when login completes. |
|
I did some more investigation into this. From the console logs and debugging, it seems that the app is reloaded even before My theory is that the server sends a 302 response to iframe, because that is how AAD works when a token is requested. Even before the angular app gets a chance to process the response, the response url (which is same as reply url registered at AAD appended by fragments) gets loaded in the iframe. Looking at the html, iframe's document object loads the html corresponding to the reply url. The another issue that people reported on this thread: digest cycles/loop when requesting token, they seem to be related to window.location.hash update causing a digest cycle. But the issue about app reloading twice on every token renewal seems to be result of AAD sending a 302 response, which causes app to reload. At this point, am not sure if we can prevent this reload at adal level or not. I have tried several things, frame onload events, using sandbox and some other stuff but none of them prevents that reload. I will continue looking into this and will update the thread if there is more info. |
|
What if AAD would accept some special parameter from adal telling it not to return to reply url? |
|
Indeed the app is reloaded in each one of the iframes as a result of the redirect from AAD. |
|
any update on why app is reloading twice? |
…irect uri. This can be used to prevent the situation where the entire application is re-created inside the iframe. See further details at: AzureAD#259 (comment)
|
Hi everyone, there is PR: #284 submitted by a community member: @Neil665 which adds an extensibility point to specify an html file that will be loaded in the iframe instead of loading the entire app. You can specify that path to This should fix the issue where app reload on every token renewal. Please note that, app will reload twice on initial login since that is a full page redirect. Update: Instead of introducing a new property |
|
Hi, Is someone able to post the correct way to set this to prevent the app from continuously reloading? |
|
Hi, Fyi, the app is in on-premise Sharepoint 2013 with ADFS and our on-premise AD synced to AAD. Thanks for any help! UPDATE: Please ignore. This was due to a bug/issue with SharePoint 2013. |
|
@bbarnwell You might not have implemented the workaround correctly. Can you please share a code repro for this issue so I can look into it. |
|
Are there any examples of this for angular 4 (2)? It's a shame the iframe causes my entire app to reload -using adal-angular4 thanks |
|
I'm facing another issue after adding the redirectUri. The only way for me now is removing the redirectUri and accept the old issue. Anyone knows how to fix it? |
and others
There is a strange issue that looks similar to other posted issues but can't quite figure it out. After logging in and being redirected back to the app the page loads 3 or 4 times in a row. After that everything works great. It appears to be triggered by the first call to a protected endpoint via $http.
I have an API on a different URL with CORS configured and oauth2AllowImplicitFlow set to true.
The general structure of the app is based on the SinglePageApp-WebAPI-AngularJS-DotNet sample.
I posted a issue on stackoverflow with more detail.
I've been fighting this for a while and would really appreciate any help or troubleshooting guidance.
The text was updated successfully, but these errors were encountered: