Trying to use it with Azure, the Azure Application requires a redirect URL set up and of course it would actually try to redirect there, so there needs to be a server behind that URL.
On the other hand, I'm just running a single webpage WebCore application in a debugger, so how can this work? Are there some magical redirect URL's that do not actually redirect anywhere and allow an SPA to complete the entire process serverlessly?
MS does seem to be using some magical redirect URL's in an msal://auth/ format in such cases, so I went ahead and set one up. It logs me into Azure, gives me a confirmation prompt and that's it: clicking on Continue in that prompt does visibly nothing, it changes the URL in the pop-up to that msal...://auth/ URL, which evidently points nowhere, and stops. The main page is just sitting there in the background, while this is happening and not reacting / not actually intercepting this and not triggering any events.
Has anyone used it successfully before? What am I missing???
And the same with redirection instead of pop-up.
BTW, pop-up does not work, without a user manually allowing it in the browser in advance. They all block pop-ups by default now.
Has this component ever worked for anyone? Are there any tricks to it, or is it just just a mirage?
My colleague, responsible for this will follow-up when back in the office next week.
Thanks!
Ok, I figured it out: the redirect URL has to match the caller's URL exactly, wherever it's called from, so when executed in the debugger, the URL would need to start with the local WebCore server, with whatever port it has configured, followed by the name of the project folder, and ending with the project.html. I.e.: just copy it from the browser when you run it.
Next, it only returns a subset of user properties in the "UserData: TMicrosoftUserData" parameter, and does not have userPrincipalName value, which I need.
It's all buried in JS (plus the structure definition in PAS), so it's not too easy to change (plus the next TMS update would override it), so I'd like to request more details in this class in the next update, please.
The data it gets from Azure includes businessPhones, jobTitle, mobilePhone, officeLocation, preferredLanguage and userPrincipalName, so it would make sense to return all of these.
And ideally the entire JWT as well - there are more details there, including the IP address of the user, as used to sign into Azure. And JWT would allow me to do an independent validation of the signature as well (which may or may not be happening in JS). - the more security checks it allows me / the caller to add, the merrier.
Would be good to have access_token as well, in case more user properties are needed. I.e.: the schema can be customized and the application may need to read values for custom user properties as well. And of course, acces_token can be configured to do other things, so without it, it's only part useful.
Another thing is that this authentication approach is still using the old method, without BFF. And BFF is the current best practice, so Microsoft (and others) would probably start breaking this old solution.
BFF can probably be implemented in XData, but before anyone starts reinventing that same bicycle over and over, do you have any plans to develop any kind of BFF component or something to cover for this?
This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.