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.
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).
Related
I'm using
window.postMessage({message: "Hello !"}, url);
to send a message from a Chrome Extension (i don't know if this is relevant) to a specific page in a window with multiples opened pages. I noticed that sometimes i have TWO pages with the same URL.
I have a simple question:
How can i be sure to which page is postMessage sending the message ?
I want to send the message to only one tab. Can i use anything else apart from the url to identify the it?
Thanks in advance !
Considering that you said you can modify the remote website's code, and I don't see how to fix the postMessage solution, here are a couple of alternatives. I would love to know if there is a way to fix the postMessage approach, as it is the recommended one from the docs!
First off, you will need to coordinate your scripts from a central background page, which can keep track of open tabs.
Custom DOM events
This is an old recommendation from Chrome docs, that was replaced with window.postMessage example. It is described here (disregard the old chrome.extension.connect API) and consists of firing a custom event in shared DOM.
So, a sample architecture would be a background page deciding which tab to post message to, and sending that tab a message via chrome.tabs.sendMessage, to which your content script listens with chrome.runtime.onMessage. The tab's content script can then communicate with the page using the above custom event technique.
One possible approach to keeping tack of tabs: have the tabs permission to be able to enumerate all open tabs with the chrome.tabs API. Your background page can then decide which tab to message based on URL.
Another possible approach, to eliminate need for the scary tabs permission, is to have your content scripts report to the background page with chrome.runtime.connect as soon as they are initialized. The background page then can keep track of all active instances of your script and therefore decide which tab to message.
Webpage connecting to your extension
This is a "modern" way of doing communication with one exact extension.
It is described in the Chrome docs here. You can define your extension as externally connectable from your webpage, and your webpage initiates a port connection with your background script.
Then, as above, you can track live ports and use them for communication, cutting out the content script middleman.
I've an app, which loads data from database. In a table I'm storing some URLs EX: https://facebook.com. Remember these URLs are dynamic and are controlled in admin panel.
Now, I need to get contents of these URLs and display it inside iFrame or inside a div within my app. Idea here is user should not go away from my app.
When I tried to load https://facebook.com it never loads because they've (X-Frame-Options) enabled.
Is there any solution for this?
You cannot tell the browser to ignore the security instructions provided by the third party site. That would defeat the object of having them in the first place.
If you want to display the content on your site, then you will have to display it from your own server (e.g. by using a server side process to read the data from the third party site and serve it from your own). Obviously, this will mean that you cannot (for example) load Facebook using the user's own credentials.
I am planning to design a web application with multiple HTML and JSP pages. The first page of myapp (index.html) loads up with the url
localhost:8080/mywebapp
without an explicitly pointing it to
localhost:8080/mywebapp.index.html
because web-xml has index.html in its startup script. Thats perfectly fine!
But how to toggle between multiple JSPs and HTMLs that are in the web app keeping the URL constant
localhost:8080/mywebapp
The user should not be knowing the navigation pattern when he is using the web-app.
Ideas on any frameworks or implementations are highly appreciated.
Thanks
Leaving aside the fact that you shouldn't do this, essentially what you have to do is bypass the standard routing method of your application.
You can do this one of two ways.
1) Use Ajax to call all the different URLs you need from within a single page. This will give you the single URL you're looking for though it doesn't of course prevent anyone from trivially working out what the actual navigation URLs are and unless you build a single page app and do some really evil interdependencies finding your navigation is trivially easy.
2) Your second option would be to create a single servlet which takes parameters which identify which part of your application you want to use. If you really wanted to be horribly evil you could hash those arguments with some form of per user short duration cookie so that even if they identify the actual web calls you're making running them manually won't actually work.
I'm building a single-page Dart web app that will essentially consist of 1 Dart file (cross-compiled to JS) and 1 HTML file that has several "views" (screens, pages, etc.). in it. Depending on what "view" the user is currently located at, I will hide/enable different DOM elements defined inside this HTML file. This way the user can navigate between views without triggering multiple page loads.
I would still like to use each browser's native history-tracking mechanism, so that the user click can the back- and forward-buttons in the browser, and I'll have a Dart Historian object figure out what view to load (again just hiding/enabling DOM elements) depending on what URL the browser has in its history.
I've pretty much figured everything out, with one exception:
Say the user is currently "at" View #3, which has a URL of, say, http://myapp.example.com/#view3. Then they click a button that should take them to View #4 at, say, http://myapp.example.com/#view4. I need a way, in Dart, to tell the browser to:
Set http://myapp.example.com/#view4 in the browser URL bar
Add http://myapp.example.com/#view4 to the browser's history
If not already enabled, enable the browser's back button
I believe I can accomplish #1 above like so:
window.location.href = "http://myapp.example.com/#view3";
...but maybe not. Either way, how can I accomplish this (Dart code communicates with browser's history API)?
Check out the route library.
angular.dart also has it's own routing mechanism, but it's part of a much larger framework, so unless you plan on using the rest of it, I would recommend the stand-alone route library.
If you want to build your own solution, you can take a look at route's client.dart for inspiration.
There are two methods of history navigation supported:
The page fragment method that you've used. Reassign the window location to the new page fragment: window.location.assign(newPathWithPageFragment). Doing this will automatically add a new item to the browser history (which will then enable the back button).
The newer History API, which allows for regular URLs without fragments (e.g. http://myapp.example.com/view3. You can use window.history to control the history.The History API is only supported by newer browsers so that may be a concern (although given that dart2js also only supports newer browsers, there are probably not too many instances of a browser that dart2js supports that doesn't support the History API).
One issue you will have to handle if you support History API is the initial page load. When a user navigates to http://myapp.example.com/view3, the browser expects to find a resource at that location. You will have to setup your server to respond to any page request by serving your Dart application and then navigate to the correct view on the client-side. This issue will apply whether you use route, angular.dart, or build your own solution, since this is a general server-side issue and the above are all client-side libraries.
I see in Javascript; Sending user to another page and how to change page from within javascript references to using the window.location to switch to a new page. It is also possible to have a similar result by including a meta tag http-equiv with a refresh value.
While these work as advertised, I need something that will continue to retry in the event the host application is not available at the time the client starts up.
A cross-browser solution would be particularly appreciated.
Update:
My current solution does as suggested. Initial AJAX to verify connectivity, followed by an update of the window.location. My concern is exactly the one given - the status can change between getting the response and updating the page reference.
I could update a lower level element body.innerHtml, for example, in the page body, but prefer to change the top level element to cleanly switch over to the new page.
The purpose of the initial page is just to bootstrap a long running application that similarly uses an AJAX loop to fetch updates of both content and periodic page refreshes. The intent is to be able to drop off web display panels and have them automatically configure themselves when they are eventually connected to a network.