We have an app that uses a custom URL scheme like myapp://foo to authorize via a third party app and then reopen the app fully authenticated. Now we also use the same custom URL scheme myapp:// for another app, but when I authenticate with the other app, it will open the old app.
Apparently this is the browser remembering what to do with myapp:// requests, but I would like to know when this cache will expire, how I can see it and how to flush it.
update: I couldn't find a way except for going into browser preferences file and deleting the entry manually. Looks like there is no other way.
Related
I'm working on a cross-platform wxWidgets-based application that uses a WebView for a web-based OAuth login to a web site. The web site's OAuth login process uses cookies to cache a login token once authenticated, so that you can go through the process again to get another OAuth token if necessary without the user having to enter their credentials again. The WebView backend implementation wxWEBVIEW_WEBKIT that I'm using in the macOS version of the app preserves cookies between restarts of my app and even reboots of the OS. This makes it difficult to test the login process.
Where is the WebView backend persisting these cookies? How would I go about clearing them?
I've already tried clearing the cookies in Safari to no avail, and I removed all of the obvious cache files I saw in the app's file accesses as captured by opensnoop, but the cached login is still present.
Per a response on the wx-users list, wxWEBVIEW_WEBKIT is implemented using a simple macOS WebView.
As noted in How can I remove cookies stored by WebView in Cocoa application?, in macOS 10.11 (El Capitan) and later, each application's WebViews have their own cookie storage and do not have access to each others' cookies.
I did not find a way to manually clear my application's cookies; I tried removing the relevant *.binarycookies file from ~/Library/Cookies but that had no effect. It's still unclear to me where the cookies are stored.
However I was able to delete the cookies programmatically using the NSHTTPCookieStorage API, following the code snippet in https://stackoverflow.com/a/8486398/60422. I ended up just adding a menu item for this to my application to clear the cookies that I only use for manual testing purposes.
I need to integrate google contacts import in my nw.js app. How should I create the google app ? When I create the app as web app, it asks for redirect uri which is not available for desktop apps. I'm not clear about how to implement google integration for desktop apps. Can anyone help me on this. ?
There is an option in OAuth for desktop applications, when instead of http://domain you will redirect to app://something and you application will be started or receive a callback.
To make this, in your application you need to open request token url in new window (new window in your node-webkit app).
Also: google docs and node-webkit github issue and other issue about this.
For me I thought better would be open a default browser, there is a high chance that user already authenticated, and then just need to click "allow". So I start simple webserver inside node-wekit app and redirect to localhost.
You can see implementation in my project https://github.com/Paxa/postbird/blob/90cfb53b1775310eb2f262c8b54c9dba15b5cc0a/app/heroku_client.js#L185
To open default browser I use command "open" (only for mac)
child_process.spawn('open', [url]);
I also try to close browser window when user redirected back, it works but not always.
response.writeHead(200, {"Content-Type": "text/html"});
response.end("<script type='text/javascript'>window.close();</script>");
May be I should also make a window active when receive redirect back (didn't try it yet):
var currentWin = require('gui').Window.get();
currentWin.focus();
If google not allows to make localhost as a callback url, you can try to use some domain (even free) and point it to 127.0.0.1 or use http://readme.localtest.me/
I have this website that I developed. It is acting weird. I logged onto it and now it seems that I can't logout of it. It has session which I don't know how it can still maintain after logging out and also in different browsers and even in incognito.
The weirdest thing is that if you open it in your browser you get same session state. You can't do anything with it. But it is jut there.
What is going on?
Go to this page, it shows some user logged in. click Add and it asks for credentials again. Like an endless loop.
http://krninstitute.com/krnitech/Forms
Then go to this page, it shows other user logged in. Go to the end of the page.
http://krninstitute.com/krnitech/Gallery
This question requires these external links.
But here are images just in case:
Edit 1:
What is causing every request to end up with session cookie? I don't have any cache implemented. Does it have something to do with recent GoDaddy crash?
Edit 2:
Questions are 1. how can you see who is logged in on the application? I haven't implemented such functionality. And 2. how there are two people logged on from same browser window?
Session and Authentication are two different things. When you use FormsAuthentication to login and logout, it does not change the session. You must abandon the session in addition to logging out to do that.
Session.Abandon();
Be aware that the session will still be there until the end of the request, so you should probably immediately redirect to a default page afterwards.
I am building a WP7 Twitter client. The normal OAuth 1.0 flow involves obtaining a request token by navigating a web browser to https://api.twitter.com/1/oauth/authenticate with my app's consumer key; this page will show a login prompt and ask the user to authorize my app to perform actions on their behalf. Upon completion, this page will redirect to a callback URL supplied by my app, with the request token supplied as a parameter.
For web apps this makes sense. I don't understand how this is supposed to work for a standalone mobile/desktop app, though. The Twitter API documentation seems to imply that this should be a feasible option. They do offer an alternative xAuth mechanism that allows an app to gather username/password itself and then supply that directly to obtain an access token. The API documentation points out that this is an inferior option (as it requires the user to trust the app, not just Twitter, with their password), but I don't see how I have any reasonable alternative?
(there is also a PIN-based option, but that's a pretty burdensome solution for the user)
I just want to make sure I'm not missing anything obvious.
"For web apps this makes sense. I don't understand how this is
supposed to work for a standalone mobile/desktop app, though."
Just embed a web browser control in your app, and navigate to the twitter authentication page. Then detect the redirection to the callback url (using the Navigating event) and retrieve the parameter. Many twitter apps do that, it's basically the same as asking the user for the login and password, except that instead of your own controls you're displaying twitter's page.
Nope, you're correct. The option for a mobile/desktop application is either a pin-based option or to use xAuth. Once you have an xAuth application has an access token it is indistinguishable from OAuth (it only changes the authorisation workflow). One thing it does change, and this is very specific to Twitter, is that if you do use xAuth then your application will not be allowed to read or write Direct Messages. See Twitter's The Application Permission Model page for more information.
I have a simple app I want to create, which allows you to place any website within your Facebook page on a tab.
Previously, I could just do this without a secure canvas URL, but now it is telling me that I must have this to create the app.
Is there a way around this, as the app does not take any info from anybody, it just shows a site from my server on the page.
Short answer: No. You do not need to provide an encrypted connection if the app runs in sandbox mode but otherwise it is mandatory.
Well, actually people using secure browsing will just see an error message at the moment but judging from recent announcements apps without an encrypted connection will be blocked a bit further down the road.