I have created an experience with custom widgets using EXB developer edition. I have deployed the experience to a web server, registered the app in my AGOL org and everything basically works. Some oddities are;
#1 - When the web app loads in the browser, they first get a small dialog box that says "please sign into ArcGIS online - ok or cancel. " If they click ok they get the sign in page. But this is a strange end user experience, as the user just expects the sign in page straight away. Is there a way to bypass this little extra dialog box?
#2- When the sign-in page displays, it is the generic ArcGIS Online sign in page, not the organizations sign in page. The user can select the option on signin page to type in their arcgis only org URL, but again that is a strange end user experience. Is there a way to make aways using my orgs ArcGIS Online sign in page?
It sounds like you did the first part:
Second, you need to define the redirects after authentication (item settings). For deployed Experience Builder apps:
https://[PATH_TO_YOUR_APPLICATION]/cdn/[BUILD_NUMBER]/jimu-core/oauth-callback.html
I hope that's helpful. Good luck!
Thanks for the tip, but not working for me, I must be missing something. I had already set redirect URL and was getting the little tiny dialog "please sign in to ArGIS Online OK/Cancel". Selecting OK would bring up the standard ArcGIS Online login (but not my orgs login).
Switching the redirect URI as above (with edits for my app location and build number) results in the same tiny dialog prompting to please log into ArcGIS Online, but selecting OK then just returns 400 error with invalid redirect URI.
I checked one of my deployed projects, and I do get the OK/Cancel confirmation dialog, requiring action before the OAuth window opens. However, the window is my Org login, or if already signed in, an approve option.
One last suggestion is double-checking the redirect endpoint. If you navigate to it you should get an "AUTHENTICATION_ERROR_CODE" in the console.
Thanks a lot for your feedback.
#1 is a limitation, but it is designed to prevent the login popup to blocked by browser and user sometimes will not notice the blocked login. Based on the feedback we do see inconvenience for some users, we will investigate to have better solution.
#2 is seems also a limitation. But you should be able to define the redirects to the org login. Does @DougLogsdon2 's suggestion work for you?