I'm trying to use Spring WebFlow to build voice application - eg. application which produces VoiceXML and is interpreted by voice browser. There is no such concept as back button in the voice application and the redirects are therefore useless and only confuse the voice browser.
I have tried the ?mode=embedded, but that has no effect. From what I understand this might suppress redirects for Ajax requests made within same view-state, but not redirects on transitions between states.
Is there any way to completely disable all redirects in spring-webflow?
Aleš
Related
I've read that the silent authentication is typically made in a 1px iFrame. What I've been wondering is how the response to the authentication request is passed back from the iFrame to the parent application. Only option i can think of is that the Auth-Server returns some javascript code that runs e.g.
window.top.postMessage('auth', 'thisisthetoken')
But that approach seems a little sloppy to me. So how does it work?
That is the traditional flow for token renewal in Single Page Apps. The initial authentication should be done on a main browser window via a redirect, eg as for Google Sign In or Office 365.
TOKEN RENEWAL LIBRARY USAGE
The oidc client library is commonly used to implement this, enabling the iframe post to be done with very little code.
IFRAME MECHANICS
The main window triggers an OpenID Connect redirect on a hidden iframe. When a response is received, the iframe uses the postMessage API to return an OpenID Connect response to the main window, containing code and state parameters. The main window then exchanges the code for tokens, using a PKCE code verifier that it saved to session storage before triggering the iframe redirect.
BROWSER SUPPORT FOR THIRD PARTY COOKIES
The above flow relies on the Authorization Server's SSO Cookie being sent in the iframe request, but browsers are starting to drop third party cookies to limit tracking - Safari already does this.
Therefore it is now standard to instead manage renewal via a secure cookie issued for the site of the web origin, and to avoid iframe post solutions.
Projects that rely on third party cookies these days will struggle - see this recent answer of mine.
HOSTING PREREQUISITES
In 2021 you are best to use secure SameSite cookies in the browser, since posting tokens between frames is vulnerable to Cross Site Scripting. Ensuring that the web origin of each frame can share a secure cookie via a child / sibling domain is therefore a prerequisite - you cannot really develop a secure web solution these days without it.
Security in the browser is a tricky topic and needs an architectural design - for more info on 2021 web security recommendations, take a look at recent Curity Web Guidance.
WITH TOKENS ONLY
This will work buy is considered very poor security in 2021:
Redirect the whole window to authenticate the user (good)
Save tokens to local storage (bad) - to deal with page reloads - easily exploited by malicious code
Then post tokens between iframes (bad) - can be intercepted by malicious code that adds a listener
I have an app on foo.com which has an iframe that loads another application from bar.com. The bar.com webapp relies on maintaining session with a session cookie which it issues on the response to the first request to bar.com. ITP at some point decides it's no longer going to send the bar.com session cookie on requests to bar.com in that iframe... and the bar.com webapp goes fubar.
The arrangement works fine if I disable "prevent cross-site tracking" in Safari. And it works fine in any other browser.
I think ITP is deciding that the cookie being loaded in the iframe is a third-party context. And although the user directly interacts with the webapp presented in the iframe (clicks, drags, etc), ITP does not register that as first-party interaction.
That's all mighty unfortunate and I'm not finding a way to work around it. Any suggestions? There are no ads or ad-tracking involved here.
If you feel there is a bug in the way ITP is handling your web app, you should file a Radar so we can investigate.
As it stands, unless your app is embedded on a number of other sites, it’s unlikely it would have been flagged as a tracker.
Can you give details about your application, and where it might be used so we can investigate?
When developing endpoints I need to follow a rather complex/cumbersome login process to authenticate with our gatekeeper.
For this I open the developer login page in Paw. It opens inside paw and renders the content properly. If I then click the button to actually login and an external browser is opened causing Paw to loose track of the proper cookies.
I wonder if it would be possible to keep the request inside Paws embedded browser so the cookies are not lost and I can continue testing my endpoints.
To be able to login using cookie-based auth, in Paw 2.1, you can use this hack: go to your web browser with developer mode enabled and login on the website. Then, in the Inspector / Debugger, go to Cookies (in Chrome/Safari: inspector is Cmd+Option+I, then tab "Resources" then "Cookies"). Copy the session/login cookie. Go back to Paw and add a "Cookie: mySessionCookie=value" header. It should do the trick.
Note: that's a hacky method. As mentioned in my earlier comment, a nicer way is to come.
I want to automate logging into a website and retrieving certain data.
I thought the way to do this would be to sniff the HTTP requests so I know where the login form is being POSTed to so I can do the same using NodeJS/Java/Python.
However I can't seem to find the HTTP request that handles it.
The site seems to use some Java-applet and a lot of Javascript.
This is the site: link
Should I have a different approach?
Also also wonder about storing a cookie session, and sending it with each HTTP request after logging in.
I'm sorry if I am not to clear, I will try to explain myself further and edit this post if needed.
You can use the developer console (hit F12) in Chrome (this works also in other browsers) and then click the "Network" tab. There you see all network calls.
To detect what http requests are performed from a mobile device, you can use a proxy like Charles Proxy.
Also be aware that if you post from nodejs the cookies won't be set in the users browser.
I have a Drupal site with user logins. Embedded within this site is a Flash application that shows some data to everybody but allows extra functionality if the user is logged on. From within Flash, I'm using XMLRPC to access the system.check method (to determine whether the user is logged in) and the user.login method (to log in a user from within Flash).
Within Flash, everything works fine. However the Flash login state does not seem to correspond to the rest of the site. For example, if I invoke user.login via XMLRPC, subsequent calls to system.check show that I am logged in, but the Drupal user page still says I'm logged out. Or if I am logged in both places and then I log out via the Drupal user page, the next call to system.check still indicates that I am logged in.
How can I make the login state consistent between the Drupal GUI and my embedded Flash app?
(Note: I am not using any XMLRPC library, I am just constructing the requisite XML manually and sending POST methods using a URLRequest object.)
EDIT: I have confirmed via this question and also via testing with a Web Proxy that the SESS cookie returned by the user login page is being picked up and sent back by the flash application.
EDIT: And now I have shown experimentally that even though Flash (via Safari) is sending the same cookie, it gets back a DIFFERENT cookie when it connects to the XMLRPC service than when it requests and HTML page. In other words, Drupal just doesn't support this kind of synchronization and I'm stuck. I'm accepting the answer below that put me on the right track.
EDIT: AMHPHP is not fully released for Drupal6 as of this writing, but it turned out to be installed on the site anyway. Using the DrupalSite library, I was very easily able to log into and out of the site from flash, and the login remained consistent between flash and HTML.
I'm not terribly familar with Flash, but do the URLRequest objects "inherit" state from the browser session, including the user login cookies? If not, you'll need to explicitly send the login cookie with your hand-built request or Drupal will think that it's just coming from another web browser at the same IP address.
If you're not quite sure, using the Firebug plugin might be useful. It lets you inspect any requests that are being piped through the browser, examine their headers, and look at the raw HTTP response object that comes back.
Update: Even more important than the flash widget getting a session cookie is the flash widget getting the SAME session cookie as the web browser itself. Drupal allows users to log in from multiple machines simultaneously, so if the browser is creating one session and the flash widget is creating another, you'd see the behavior you're describing...
It can't be done.
(For details, please see my final edit to the original question and the equivalent information in my comment to #Eaton.)