My OSX application is required for authentication based on Kerberos protocol.
For login I'm using WebView (and WKWebView for MAC OSX > 10.9) by load the authorization URL request.
The login works as expected, but it remains logged in until I log out from my computer or killing my application.
It means that at the next time I load the authorization URL request then I logged in automatically without being promoted to insert my user & password.
Before I load the authorization URL I delete the cookies from [NSHTTPCookieStorage sharedHTTPCookieStorage].
How can I log out?
You need to destroy the kerberos tickets on the machine the web browser is running on.
/usr/bin/kdestroy
OS X used to have a graphical interface for managing tickets, but I think that is long gone. You should only be doing this for testing. Kerberos tickets are shared among many applications in OS X and if your app blows away the ticket, your users will come after you with pitchforks...
My solution is to close my application by:
[NSApp terminate:self];
A better solution will be to relaunch the app but this is enough for me right now.
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 have to implement a scenario in which if user login to 2nd device or mobile-web then the first device/web should be logged-out.
Both app & mobile-web are running on the same MobileFirst server and are using the same adapters and having almost same functionality.
I am not sure if such type of provision provided in MFP.
I am open to suggestions or guidance.
MFP doesn't support that. I know some application has similar feature,
I believe it's up to user code.
Would you check this information?
https://www-01.ibm.com/support/knowledgecenter/SSHSCD_7.0.0/com.ibm.worklight.dev.doc/dev/c_oauth_security_model.html
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_chapter09186a0080153e60.html
How to logout previous session of a user,if he logins again on same or different browser
http://webcache.googleusercontent.com/search?q=cache:jbA-CDEbHowJ:stackoverflow.com/questions/1416732/how-to-logout-previous-session-of-a-user-if-he-logins-again-on-same-or-different+&cd=1&hl=en&ct=clnk&gl=us
I have made a Facebook app in Ruby (using Sinatra and Koala), deployed it on Heroku and sat up all the settings and it works that way, but now I have to debug some functionality and for that reason I need to run application from localhost (using foreman start).
I have read somewhere that I should make development version of my app and specify site url to localhost:[port_num] and I have done so.
The problem is when user(me) reach localhost:5000 and application redirects it to Facebook to get permissions (when Facebook login dialog should appears). At that point this error occurs:
App Not Set Up: The developers of this app have not set it up properly for Facebook Login.
I saw this issue but in my development version of app there is no status and review settings and I don't see how to make application alive.
How to set up my app for Facebook Login while it runs on localhost?
or
What is the proper way to run Facebook app from localhost to get full functionality?
The problem laid in Advanced settings in security section - development app "inherits" settings from base app so in Settings->Advanced->Security->Valid OAuth redirect URIs was initially url of my base app not my localhost:5000 and it causes a problem. One of solutions is to leave this field empty (and leave app open to redirect attacks) or to fill this field with your Site URL.
It seems that development version of an application can't be "alive".
To allow Facebook Login for users of your development app you should register them as testers under Roles tab.
I'm using a webview to host a log in page that redirects to an ADFS server to offer single sign on. This works on 10.9, but I noticed for OSX 10.10 I am able to get to the point where the ADFS server will present an http authentication challenge, the webview will show the default dialog to enter credentials, but after entering the credentials I never see the expected redirects that eventually allow the single sign on process to complete. Even if I cancel the webview prompt to login, I never receive a didReceiveResponse message (in the WebResourceLoadDelegate protocol).
Does anyone know of any changes in the webview for 10.10 that may cause it to stop sending/receiving requests/responses like this?
Update: It looks like this issue is a problem with WebViews and HTTP Basic Authentication in general. I have created a simple mac application with a single web view, and pointed it to a apache web server with a folder protected by an .htaccess file. While the app is able to successfully view the actual web page after the user enters their credentials in the login prompt on 10.9, on 10.10 this fails in the same manner as described above.
Sometimes, the login screen will appear if the user clicks the back button and then chooses another link, instead of the content that should be displayed. It's like the application suddenly thinks the user is not authenticated. The user then has to re-authenticate to continue browsing. This happens while the user is actively browsing, so no timeout should occur, and after authenticating, the content is shown (so it's not an authorization problem).
This problem is unfortunately quite difficult to reproduce. The user who has experienced the problem most often is using Windows XP with IE 7, but the problem has also appeared with Windows XP and IE 8. I can't seem to reproduce the problem on Windows 7 with IE 9 or Chrome 18, but because the problem is difficult to reproduce, I can't say confidently that the problem is browser or browser version dependent.
Our ASP.NET MVC 3 app uses Forms Authentication with role information stored in a SQL Server database, and membership information in Active Directory. Hosting environment is IIS 7.5 on Windows 2008 R2.
Has anyone else seen this problem, and know of a workaround?
On the server, I guess that you are using a custom IPrincipal which you need to reattach to the request thread for each request? Are you doing this in an HTTPModule or in global.asax? What page event are you hooking into to authorize the thread?
I have noticed differences in authentication being available in different runtime contexts dependent on which event I use. I now always use OnAuthorizeRequest and check that application.Context.User != null.
But the symptoms you are describing sound more like the authorization cookie is missing from the request intermittently.
Add some debug logging for each request and monitor cookies and authorization to see if you can detect the conditions that cause it.