I am using the Aurelia OIDC plugin for authentication. One of the things that needs to occur is silent renew of the token. This occurs in an iframe. This file is very simple and I don’t want it to run as an aurelia route because it will cause the full aurelia life cycle to run, is there a way around this, can the router be configured to just serve this without the application life cycle? I may have to not use the aurelia oidc plugin to hopefully get around this.
I’m afraid I don’t fully understand your question
The Aurelia OIDC plugin handles the silent renew functionality for you AFAIK, set automaticSilentRenew: true, and you should be good to go?
I’m not sure what we are doing wrong then, we had to provide a custom signin redirect file which gets routed to on silent renew (since it’s in an iframe, it seems like a complete site load occurs).
Unfortunately like many things with aurelia the documentation/explanation of the sample is severly lacking. Very little is described as to what the plugin actually does.
My signin file performs some logic to redirect the user to the route they tried going to on normal signin and calls userManager.signinSilentCallback() when it’s silent,
The only thing you should do in order to get silent renew working:
- edit your index.html file like this:
<body>
<div aurelia-app="main">
<script
src="scripts/vendor-bundle.js"
data-main="aurelia-bootstrapper"
></script>
</div>
</body>
see: https://github.com/IdentityModel/oidc-client-js/issues/171 for the reason why
- configure automaticSilentRenew: true like I mentioned before
Let me know if you have issues with this, that should be all you have to do
That’s what we have, the issue is with the original route being redirected to after login, which is why we provide our own signin.
Even without our own file, going back to basics as you mentioned above, we are still seeing all of our plugin console messages when a silent renew occurs. If i can stop that from occurring then I’ll be happy. I was attempting to have my signin file be a static file to elminate the heaviness of spinning up the aurelia app just for the silent renew. I have another post about delayed plugin loading.
This is all occuring silently, so maybe it doesn’t matter, but we did have to up our timeout to get it working.
Thanks for your help
What OIDC server do you use? The Aurelia app should redirect to your OIDC server and back on login, the silent renew should open an IFrame to your OIDC server, so your aurelia app shouldn’t reload at all?
Are you using push state routing?
we are using pushstate
I’m unfortunately out of the office today, so i can’t run real code. OIDC is working fine. login does redirect, but the plugin doesn’t handle a deep link route, which is what I set out to fix.
I’ll try and determine if the silent renew is what is causing a site load in the iframe. I’m not sure what else would cause it, its the only thing that makes sense.
Silent renew still runs the login redirect code which is why there is a full aurelia site load in the iframe
It shouldn’t, and everything you tell me should just work, including deep-link redirect…
Perhaps you could send me a minimal reproducible example of this? Or we could set up a screen share?
PM me on gitter or discord if you need further assistance
Sorry, that is not possible. I’m not the guy that implemented the server side code and this code is not internet accessible.
I’m not sure how the plugin handles deep linking, the plugin code is completely missing the code that all the vanilla js samples show to handle it. The plugin simply takes the application to the redirect route ignoring the original.
Either my team is completely missing something or there is another fork of the plugin
Try navigating to https://your-oidc-server/connect/checksession
And inspect the source, there shouldn’t be anything aurelia related in that page
As for the deep linking, the aurelia plugin stores the original uri in a ‘loginredirect’ query parameter which it urlencodes: https://github.com/aurelia-contrib/aurelia-open-id-connect/blob/079192b8baa0bbfb4600bda6006e81091b1148de/src/open-id-connect-authorize-step.ts
This is sent to your OIDC server though, so perhaps the server doesn’t return this properly