Dear Forum Members,
I am having trouble with MSAL Plugin, when set to true value of brokerRediectURI it stopped working with message as :
However when set to false it works like charm.
I am not sure, if it's issue with broker or the plugin itself on android.
Any help would be appreciated.
Hello Community Members,
I will appreciate any help on this.
Best Regards,
Lakshya Verma
Hello @Walter Robins,
Could you please help here a bit, I am trying hard but could not reach any conclusion
Hello @Walter Robins and Community Members,
I hope everyone is doin great.
I had a great difficulty in getting the broker fixed with this version of the MSAL Plugin. I did everything in my area of expertise that could help solve this issue but this is not working for me.
I tried to use MSAL plugin demo itself which also fails when broker reidirect is set to True.
I will be really greatful if any help could be provided on this area.
Thanks in advance.
I would like to join Lakshay on this thread and note that I am having the same issue and I am not really sure where to go from here. The difference for me is that I have updated the preferences on the plugin to use the cordova plugin release v#4.1.1 as that was the noted fix for the opentelemetry-bom issue folks seemed to be having.
@Walter Robins hope you might be able to shed some light on the issue or perhaps anyone else in the community that might know what's going on.
I found an answer for my problem, although I'm not sure if it will apply more broadly.
Basically, the way the plugin is set up, you have the MSAL Plugin application with its own extensibility configuration and your consumer apps which also have their own extensibility configurations. One thing that's a little unclear in the documentation is the difference between having 1 app that consumes the MSAL plugin component and having more than 1.
When you have 1, you can set your plugin URL and your KEY_HASH value in the extensibility configuration of the MSAL Plugin and then everything is good to go. When you have MORE than 1 consumer, that's where things get a little weirder. The problem comes in with the KEY_HASH variable that Android requires. Basically you are associating the hash of the keystore you use to sign the android app, the consumer, but you are setting this variable in the plugin member of the MSAL Plugin component. But what if you want to support more than 1 mobile app in your factory?
Essentially what I did was take the plugin member from the MSAL Plugin extensibility configuration and put it in the extensibility configuration of the consumer app where I also provided the KEY_HASH variable. I then deleted the variables member from the extensibility configuration of the MSAL Plugin. Once compiled and running on my phone, I found that suddenly if I had "BrokerRedirectUri" set to "True" literally nothing would happen when I tried to kick off SignInUserInteractive. No error messages, no console messages, nothing.
I discovered the problem on accident by desperately testing everything I could imagine. Finally, I removed the extensibility configuration in MSAL Plugin completely and just left the plugin extensibility configuration in my consumer app. Suddenly, it started working. Basically this is what my extensibility configuration for MSAL Plugin looks like now:
{ }
Note that it needs to at least have these since Lifetime won't accept a blank extensibility configuration.
So in the end it would seem that this (probably common?) error was due to installing MSAL in my consumer app twice. There may be a better way to do this and if anyone has an answer to it, please let me know. But this is what I have for now.
Hi,
We had a similar problem: 2 mobile apps (consumers) wanted to use the MSAL plugin (producer). Besides we wanted to use BrokerRedirectUri parameter to true because our scenario was:
The result was "No error messages, no console messages, nothing." too. The reason is this code in the msalInit function of the plugin:
In the logcat we had this error because of the line 'e.printStackTrace()':
"MsalClientException: The redirect URI in the configuration file doesn't match with the one generated with package name and signature hash. Please verify the uri in the config file and your app registration in Azure portal. We expected 'msauth://xxxxx/yyyyy' and we received 'msauth://xxxxx/zzzzz'
The keyHash is new in every MABS compilation (the signature hash of the package is changed every time) so it was a problem for us. The keyhash must be the same in the OS plugin, MSAL library and the Azure Service Principal.
Finally, we forked the code in this plugin (https://github.com/dvaellop/cordova-plugin-msal) in order to calculate the correct keyHash (expected vs received). For this, the configured keyHash is "". This keyHash is used to inform the signed hash to Azure Service Principal.
Kind regards, David.
I see the code changes you made in your fork, but I am not sure how they work honestly. Microsoft documentation just says you need the hash of the keystore (and alias) used to sign the Android app, not the hash of the whole app package. As I mentioned in my last message, you can just set the extensibility configuration of the MSAL Plugin in Lifetime to be { } and then set your plugin with the KEY_HASH variable in the consumer app in Lifetime:
To get the hash, you really just need to get use openssl with your keystore file:
`keytool -exportcert -alias yourkeystorealias -keystore path/to/your/keystore/file.keystore | openssl sha1 -binary | openssl base64`
Hope I wasn't completely misunderstanding the issue you were experiencing. I also have had to fork the component at this point to try and get things to work. I think there may actually be a bug in the objective-c library which prevents the auth broker from opening in iOS. If that's the case, I will find out and circle back to this thread.
Hello @Grayson Udstrand & @David Vaello ,
First of all, thank you for providing explanation on the issue.
I agree with what David said, When I used the logcat, It came with same error message as below.
Updating the hash resolved our issue, Surprisingly the hash that we used is the old hash that we used to compile the app on older version of MABS. I was not able to complete my RCA but found the solution and moved ahead.