You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- [ ] bug report -> please search issues before submitting
- [ ] feature request
- [ x ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)
Minimal steps to reproduce
Our customers follow the directions in readme file to connect to their own tenant
-clone the repository
-build in Android studio
-create App Registration in Azure Portal
-create redirect Uri using the package name and Hash generated from the Azure Portal instructions
-create json config file and intent-filter based on the information generated in the Azure Portal
Any log messages given by the failure
This produces an Msal exception:
com.microsoft.identity.client.exception.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.
Expected/desired behavior
Our customers should be able to get our fundamental sample working with their own tenant by following the directions in the readme and official documentation
OS and Version?
Any recent version of Android
Versions
2.21
Mention any other details that might be useful
Hi Team!
I am a Microsoft Support Engineer who supports Msal. Our customers are frustrated with this sample because it cannot successfully build the PublicClientApplication when the customers follow our readme and official documentation to use it with their own tenant.
The reason for this is that the sample contains its own keystore and points to this keystore in the build files. The official guidance on getting a debug Signature Hash will produce the default debug Hash for the customer's instance of Android Studio; however, this sample builds with its own Signature Hash. So by following our guidance, the customer is actually using the incorrect Signature Hash to generate a redirect Uri and intent filter.
This can be resolved by explicitly explaining how our customers can customize their keytool command specifically for this sample. (Basically the customer needs to change the path to point to the project's keystore).
Even just pointing out the fact that the sample uses its own keystore and the customer will need to adjust the keytool command will be a great improvement.
Step 5 in the portion in the readme about using your own App Registration might be a good place for this:
Thanks! We'll be in touch soon.
The text was updated successfully, but these errors were encountered:
mbukovich
changed the title
Readme instructions do not
Readme instructions do not produce correct Signature Hash
Oct 26, 2021
PramodKumarHK89
added a commit
to PramodKumarHK89/ms-identity-android-java
that referenced
this issue
Aug 26, 2022
This issue is for a: (mark with an
x
)Minimal steps to reproduce
Any log messages given by the failure
Expected/desired behavior
OS and Version?
Versions
Mention any other details that might be useful
Hi Team!
I am a Microsoft Support Engineer who supports Msal. Our customers are frustrated with this sample because it cannot successfully build the PublicClientApplication when the customers follow our readme and official documentation to use it with their own tenant.
The reason for this is that the sample contains its own keystore and points to this keystore in the build files. The official guidance on getting a debug Signature Hash will produce the default debug Hash for the customer's instance of Android Studio; however, this sample builds with its own Signature Hash. So by following our guidance, the customer is actually using the incorrect Signature Hash to generate a redirect Uri and intent filter.
This can be resolved by explicitly explaining how our customers can customize their keytool command specifically for this sample. (Basically the customer needs to change the path to point to the project's keystore).
Even just pointing out the fact that the sample uses its own keystore and the customer will need to adjust the keytool command will be a great improvement.
Step 5 in the portion in the readme about using your own App Registration might be a good place for this:
The text was updated successfully, but these errors were encountered: