I have an app that has a login/logout functionality. Upon logout, I am clearing the entity variable. How do I force the app to rerun the initial rule and display the login form?
You can have the initial rule run again by carefully crafting the select statement of the initial rule. Assuming that you are running the app in the browser, the initial rule fires on web pageview, and the logout click fires a custom logout web event, here is what I would do:
rule initial_rule {
select when web pageview "awesome*Regex(here)" or web logout
pre {
// do cool stuff here
}
{
// fire actions here
}
// postlude block of choice here
}
Related
I have a requirement ,in app I need to navigate the user to webview (website) and there will be a form with 5 fields and once the form is submitted a flag to be passed to app and app should work based on the flag .. So how it can be achieved
I have checked that there is a url_launcher or webview_flutter but i don know how to redirect the app once the form is submitted in website
I am not entirely sure if I understood the problem. But here is what can be done.
Open url in webview.
Now you should listen to webview state change. There must be a listener for this. say the listener is webViewStateChanged which will give you the state of webview.
Then you can check like
void webViewStateChanged(WebViewStateChanged newState) async {
if (newState.type != WebViewState.finishLoad ||
newState.url != desiredURL) {
return;
}
// At this point, you want to return to your app. If you need data from
// website, you can do so by accessing cookies of webview.
// Now you are back to the app, you can pop/replace the webview whatever
// is your requirement.
We are using ADFS 3.0 with several apps as relying parties. When signing out from a web application the app redirects to:
https://fs.company.com/adfs/ls/idpinitiatedsignon.aspx
That page then has a Sign in button and a Sign Out button with two options:
Sign out from all the sites that you have accessed (selected)
Sign out from this site
The user selects one of those options and then clicks on the Sign Out button. Is it possible for us force the Sign Out button to be pressed (with the default option) so that the end user doesn't need to do anything?
Looks like I figured it out: the signout page loads a javascript file which can be modified (onload.js). I added a javascript function to that file which sends a click event to the signout button.
On the ADFS server open PowerShell. See the currently active web theme:
Get-AdfsWebConfig
This was set to Default. Then create a custom web theme based on the default web theme:
New-AdfsWebTheme -Name Custom -SourceName Default
Export the web theme for editing:
Export-AdfsWebTheme -Name Custom -DirectoryPath C:\temp
The file that needs to edited is: C:\temp\scripts\onload.js. Add these lines at the end (I got the ID of the Sign Out button by inspecting the source code of the signout page):
var signOutPanelExists = document.getElementById('idp_SignOutPanel');
if (signOutPanelExists)
{
// only click the SignOut button if it is displayed - to avoid endless loop
if (document.getElementById('idp_SignOutPanel').style.display != 'none')
{
var logoutKnopf = document.getElementById('idp_SignOutButton');
if (logoutKnopf)
{
window.onload = function(){ document.getElementById('idp_SignOutButton').click(); }
}
}
}
Upload the modified onload.js:
Set-AdfsWebTheme -TargetName Custom -AdditionalFileResource #{Uri='/adfs/portal/script/onload.js';path='C:\temp\script\onload.js'}
Activate the custom web theme:
set-adfswebconfig -ActiveThemeName Custom
Now when the user logs out of the web app he gets logged out completely w/o having to press another sign out button.
More info on editing the signin and signout page:
https://technet.microsoft.com/en-us/library/dn636121(v=ws.11).aspx
I added session using play framework. Session works fine,but after logout page redirected to index page(login page).Then click on back or forward button again enters to home page. I have started new session on logout,then also it enters to homw page.How to show the same index page on back or forward button click?
def login = Action {
{ implicit request =>
val email = request.body.asFormUrlEncoded.get("email")(0)
val password = request.body.asFormUrlEncoded.get("password")(0)
loginForm.bindFromRequest.fold(
errors => BadRequest(html.index(emailForm,errors,"Please enter valid username password")),
contact => Redirect(routes.Application.home).withSession("email" -> email,"password" -> password)
)
}
}
def home = Action { request =>
request.session.get("email").map{ user => Ok(views.html.home())
}.getOrElse{
Ok(views.html.index(emailForm,loginForm,""))
}
}
def logout = Action {
Redirect(routes.Application.index).withNewSession
}
To prevent browser back/forward buttons from navigating to a logged-in screen, you need to have two mechanisms in place:
Tell browsers that they should always hit your server for any of the web pages that sit behind your login screen.
Decorate every action that serves back one of your secured web pages with a check to see whether the person making the request has logged in. The check should then serve back the index page if they don't have anything within their cookie that conveys their identity.
The first of these can be achieved by getting your actions to set the following header in the HTTP response:
Cache-Control: no-cache
From this tutorial:
no-cache — forces caches to submit the request to the origin server for validation before releasing a cached copy, every time. This is useful to assure that authentication is respected (in combination with public), or to maintain rigid freshness, without sacrificing all of the benefits of caching.
You may already have the second mechanism in place. If not, you'll have to write an action that performs the check.
The recommended way to then apply both of these mechanisms to all of your pages would be to use action composition.
I'm using Activity/Place in my GWT project, if current user is not logged in, when he navigates to some Place, the user will be redirect to login page, if the user has logged in, then he will be taken to that Place. How to implement this logic efficiently?
I tried to hook PlaceChangeRequestEvent:
eventBus.addHandler(PlaceChangeRequestEvent.TYPE,new PlaceChangeRequestEvent.Handler() {
#Override
public void onPlaceChangeRequest(PlaceChangeRequestEvent event) {
Place newPlace = event.getNewPlace();
if (newPlace instanceof MyProtectedPlace && userNotLoggedIn()) {
event.goTo(new LoginPlace());
}
}
});
Unfortunately it does not work since the ongoing request for MyProtectedPlace is not cancelled.
Yes I could check this when user are about to navigation away from current place, but this will not be efficient as the check logic will scattered throughout the program.
Thanks.
You can do it a little bit differently I think. Let's say that you want a place called SecuredPlace to be accessible only after login. You have a corresponding SecuredActivity.
What you can do is, when you start your SecuredActivity, you check if your user is logged in. If not you do placeController.goTo(new LoginPlace ()).
If the user is logged in then you continue. As the start is called by the framework there is no way to skip this step which in my opinion makes it secured enough.
But you should implement your security on network calls to your backend not on places. Every time you call the backend, you check that user is authenticated and has the right credentials. If not you can intercept the callback, check that it is a 403 error and then redirect automatically to your login page. Because if your backend calls are not secured, securing your places is useless.
So Intuit charges for each active connections to QuickBooks. Therefore, I want to restrict the QuickBooks functionality in my application to premium users only.
Ideally when any user clicks the "Connect to QuickBooks" button and my RequestOAuthToken http handler is called, I want to check if the user is allowed to use QuickBooks. If that is the case, then the normal OAuth flow continue. If the user is NOT allowed, then I want to redirect the user to the upgrade page of my app.
Given that the "Connect to QuickBooks" button opens a new window (at least on desktop, I haven't tried on phone/tablets), the window should get closed, and the main window (my app) should redirect the user to the right page. And actually this is exactly what happens if the normal OAuth flow completes.
Now, I have tried a few different approaches but I couldn't get it working.
1) In my RequestOAuthToken, return a HTTP redirect to the plan page
2) In my RequestOAuthToken, return an html page with javascript logic to redirect to page
3) In my RequestOAuthToken, return HTTP redirect to a page with javascript logic to redirect to page
4) I haven't tried that one but could I somehow intercept the javascript click handler on the Intuit button. I'm not sure if that is an accepted practice.
Here is the piece a javascript I grabbed from the .Net sample:
try
{
var parentlocation = window.parent.opener.location.hostname;
var currentlocation = window.location.hostname;
if (parentlocation != currentlocation)
{
window.location = plansUrl;
}
else
{
window.opener.location.href = window.opener.location.href;
window.close();
}
}
catch (e)
{
window.location = plansUrl;
}
Help me out please.
I don't think you'll be able to do exactly what you're asking, but you can probably come close by taking a different approach.
Rather than trying to redirect them after they click the button, why not try to redirect them before they click it? e.g. when they try to get to the page that has the "Connect to QuickBooks" button it, check if they are a premium user there, and redirect them if they are not.
I don't think you'll be able to redirect them after they click the button because once they click that button, they get kicked over to Intuit's website and it's beyond your control at that point.
Clement, Keith has provided the answer we would want you to pursue. You may not alter the behavior of the Connect To QuickBooks button. It must be used as described in our documentation. Providing a link to a page that shows the Connect To QuickBooks buttons for your premium users and an upgrade message to non-premium users is the way to go.
I highly recommend that you visit http://docs.developer.intuit.com/0025_Intuit_Anywhere/0010_Getting_Started/0040_Publishing_Your_App and review all of the documentation there. If you develop with our guidelines and requirements in mind it will speed up the review process.
Tony Purmal
Developer Relations Engineer
Intuit Partner Platform