Create menu item link to card works on desktop but mobile app requires logging in again

Question

We would like to make a menu item redirect to a card we created. When we put in the new redirect link it is prompting us to login on again but only on mobile app usage; Desktops work fine.

Thanks

REF CASE # 14307579

So when updating the OLB menu link, having one of the menu options go to one of our dashboard card URLs, the change works fine for Desktop users (as opposed to mobile app users where it works but requires logging in for a second time).

The second of three methods or platforms would be the rare method of going to OLB url via the mobile browser... there if going to the desired URL afterwards also seems to work.

However, the third method and encouraged why is to use the CUTX mobile app (which is just the same browser wrapped in an app pointing to the OLB URL for starters. The problem lies here when going to the menu and URL for that same item, it fails.

I believe the first two methods keeps the session information and everything works. The third and desired method fails due to session loss.

The question, I believe is how to have the URL keep and maintain the session as desired and hence the URL should work.

Or it could be something completely different. Either way, we need a solution for links to work from the mobile devices without requiring members to log in again.

Answer 1

The alternative way to interpret this question is 'how do I have one web server + URL handle authentication from Banno's Authentication Framework e.g. for a sidebar navigation menu item and a plugin card?'.

In that case, it would be possible but you would need to have two External Applications defined.

Recall that an External Application can have one, and only one, defined link type. As an example, plugin cards use the PluginCard link type. Creating an External Application with the PluginCard link type makes that External Application eligible to be configured as a plugin card for the Dashboard.

It sounds like you are hoping to use something like the DebtRelief (Loan assistance) link type, since that falls under the category of "Main navigation links". Unfortunately, there isn't any to have an External Application with two link types, nor is there a defined way to 'redirect from this link to that link' when it comes to plugin cards.

A way that you might handle the 'how do I have one web server + URL handle authentication from Banno's Authentication Framework e.g. for a sidebar navigation menu item and a plugin card?' question:

Assume that your institution has its own web application server that can handle authentication requests at a Redirect URI, for example https://myawesomeinstitution.com/developerstuff.

In this case, you could set up an External Application with link type PluginCard and Redirect URI of https://myawesomeinstitution.com/developerstuff that you can use for the plugin card. You could set up a separate External Application with link type DebtRelief (as an example) with that same Redirect URI of https://myawesomeinstitution.com/developerstuff. This would give you the UX that you want, i.e. a sidebar navigation menu item and a plugin card, while keeping development costs pretty low since it all uses the same Authentication Framework.

If you wanted to somehow differentiate the UI presented to the user (e.g. if the UI you want for the plugin card wouldn't make sense as a launching point for when the user clicks the sidebar navigation menu item), then you could adjust the above by setting up slightly different paths such as https://myawesomeinstitution.com/developerstuff/sidebarthing for the sidebar navigation menu item and https://myawesomeinstitution.com/developerstuff/pluginotherthing for the plugin card. That would use the same web application server, just handling different routes so they can serve up different content.

As an aside, it's entirely possible that your web server may not be selecting the correct credentials (Client ID + Client Secret) if there is only a single URL being used (e.g. https://myawesomeinstitution.com/developerstuff from the example above). That would certainly explain why Banno Mobile seemingly requires an 'unnecessary' login since there is a mismatch between the credentials expected for the sidebar navigation item versus the plugin card (or vice versa). Using two different URLs (handled by the same server) would make it easier to ensure that the correct credentials are being served in the right context (e.g. the hypothetical examples from above of https://myawesomeinstitution.com/developerstuff/sidebarthing and https://myawesomeinstitution.com/developerstuff/pluginotherthing).