I'm working on a windows based application in C++ that requires facebook login. I'm using using Ole Embedding/ActiveX control with the CLSID_WebBrowser component (IWebBrowser2) to do the authentication.
This works pretty well in so far as I create a window, embed the activeX web browser control, and then I direct it to the facebook login with an 'authorization url', such as...
https://graph.facebook.com/oauth/authorize?client_id=xxxx&redirect_uri=https://www.facebook.com/connect/login_success.html&scope=basic_info
xxx is set to our app id.
This works, and you can login. The problem is if I quit and restart the app, even if I've selected 'keep me logged in' in the web page, I will generally have to retype in my password.
I say generally, because if I don't use the facebook auth url above, and say go to www.facebook.com, within my active x control and log in - it will remember that I'm logged in, and I don't have to type in password if I shutdown and restart the app.
As another side detail all of this is separate from the behavior of just running IE. If I run IE and login - it has no effect on the login inside of the app. And it's not something that is unique to my implementation of ActiveX control embedding. If I run the JUCE library demo - which has a web browser active X component, it has the same behavior as with mine. That is...
1) I can login via https://graph.facebook.com/oauth/authorize - but if I restart the demo, it won't remember my previous login
2) If I login via www.facebook.com then it does remember I've logged in
+ Actually a login like this in JUCE will allow me to login without a password from my app
3) Login from IE has no effect
It's tedious to have to login every time, and seems like incorrect behavior to have to do it if you select 'remain logged in'. It does not appear that it's a problem with the ActiveX control saving session state - as session state is maintained when I use the www.facebook.com login. It may be worth saying - I can't use www.facebook.com login, because it doesn't return the information that the app requires to work, that's what the authorize style url is all about.
The implication seems to be that facebook is doing something different in these scenarios - it's not storing the login information if you use the authorization url.
So my question is how to fix the problem - such that 'remain logged in' will remain logged for an application authentication through the authorization url?
I guess as a work around, you could store the authorization token in the app, and try and see it that token is valid at startup perhaps. I'm not sure that's the 'right' way to do it.
Also note - my original implementation used Ole Automation (effectively my app controlled a separate IE process), and it had none of these problems. BUT unfortunately with IE 11, Ole Automation seems to have been broken.
Thank you for your time and wisdom.
I didn't find away to honor 'keep me logged in' within facebook. Instead, if a user logs in I store the authorization token encrypted in a file. If they restart the application, it will attempt to login using the stored auth token. If it fails, a standard login sequence is pursed. This is equivalent to acting as if 'keep me logged in' is always set, which isn't right, but is better from a usability point of view than the opposite.
It may potentially be possible to lookup the 'keep me logged in' element from the DOM of the webpage, and see what it is set to. This seems kinda fragile.
I remain open to suggestions on, how to 'do this properly'.
Related
I created a static Web site using Azure Static Web Apps (under the Free plan for now -- not sure if that's relevant to the issue at hand.) I can access the Web site through an ***.azurestaticapps.net URL.
I then tried to test Azure Active Directory authentication per Microsoft's instruction from this page:
https://learn.microsoft.com/en-us/azure/static-web-apps/authentication-authorization
My problem is that logging out does not seems to work as I would expect on a normal Web site. I could log out, but when I tried to login again (hoping to use a different Azure AD account,) the Microsoft login screen flashes by and I got logged right back in with the user that I just logged out from. Switching to a different tab doesn't help.
Steps to repro:
Navigate to /.auth/login/aad and login using a Microsoft Account. Say NO to 'Stay signed in?' prompt.
Navigate to /.auth/me to see the basic information on the logged in account to prove that I'm in the logged in state.
Navigate to /.auth/logout to logout. Immediately, navigate to /.auth/me again to confirm that my static Web App regards me as 'logged out.' I'd see this:
{"clientPrincipal": null}
Navigate to /.auth/login/aad again. Microsoft login page flashes by, and I am logged right back in with the previously logged out user.
Things that sort of worked
Any of the two actions below alone seems to make the browser forget my logged-in state:
Close the whole browser and relaunch it. I'd get asked to pick the previous user (and then enter the password) or choose a new user. This sort of works but reminds me of some Web sites 15-20 years ago that said 'For security reasons, please don't forget to close your entire browser after logging out from this one tab.'
Open a new tab in the same browser, and navigate to hotmail.com. That tab will enjoy my logged-in state from the Static Web Apps tab. I'd see my mails right away. Then I log out from the hotmail.com tab, switch back to ***.azurestaticapps.net tab and see that I am still logged into my Static Web App. Good! Then if I log out from my Static Web App and try to log back in, it has forgotten my logged-in state this time. In other words, logging out from the hotmail.com tab is somehow more powerful.
I also tested /.auth/login/google too and the same problem arises! So the issue seems to be on the Azure Static Web Apps side, not how idPs handle their logout process.
Am I missing anything obvious?
I must use facebook integration within desktop app on OSX. I've used part of facebook sdk for ios and modified all ui elements to properly work on desktop.
I'm presenting facebook dialogs within webView, display is set to popup, and redirect url is https://www.facebook.com/connect/login_success.html.
Everything seems to work fine (all the dialogs are working after login, token and expiration date seems to be ok and are stored between web sessions) except for the facebook cookies which are always set to be session only (even with the keep me logged in option turned on). This means user has to log in to facebook everytime app is opened which is really frustrating.
I've already tried setting display to other values (touch, page) with no success. Probably all relevant settings in facebook app are checked (Native or desktop app?, Embedded Browser OAuth Login, Client OAuth Login).
so the question is if anyone has encountered same problem or might know the solution to make keep me logged in option working properly?
When a user is not logged in and they navigate to a page tab made with our app, they get an obtrusive dialog asking them to log in:
This has nothing to do with http vs https, the app is not in sandbox mode, there is nothing in the tab asking for a login or user information, etc. I've gone through the app settings at least a half dozen times now, and nothing is wrong there. Aside of urls, the settings are identical to another app I have that does not suffer from this problem. I'm stumped!
Edit: here is an affected tab: https://www.facebook.com/StaticHtmlThunderpenny/app_203351739677351
This message is not about login to your app, but Facebook in general.
So my guess would be that the page your app is installed as page tab app on is restricted in some way – by age, location, or for having alcohol-related content. And then of course Facebook asks for login, because otherwise they can not determine whether or not the (as of now still “anonymous”) user qualifies to see the page.
So go check the page settings.
This is actually not app related question.
This is thumb rule!! To access any app on Facebook, you need to log in to Facebook. You can see Facebook page without log in. But for facebook apps, you should be authentic user.
with this issue in my own experience that I came across some years back with a facebook app that I was running, if this doesn't relate to any of your other social networking apps then am aligning two set of possibilities and solution.
The user might have not properly logged out as "written" in the app for the users logout stage.
Solution would be that the user logout as expected before closing the app.
The user might have set up an automatic login prompt which was removed by the app when it was been updated automatically. (If you do get me???)
Solution would be to monitise your app on updates and login informations or better still just login and logout ask intended by the app and for security reasons.
Lastly I would say that automatic bookmark database should be added to the server part so current pages as the user uses the app would be saved after logout or login stage. Thank you, hope this helps and if not let me know what am missing.
I'm building an iPhone app that, in part, allows the user to log in to, pull data, and post data back to a Wordpress site (more specifically, Buddypress). One way I'm considering approaching this problem is to use a series of UIWebViews to display the mobile-themed version of the site.
Ideally, I want the user to be able to, upon first-launch of the app, input their username and password, and then never have to do it again (functionally similar to tons of other social apps out there, like Facebook, Twitter, etc.)
Here's my question - obviously it is easy to store the user's login credentials, but how do I, in the background, establish an authenticated and persistant session with those credentials each time the app opens, so for the user, they are never presented with a login screen again, and can just use the app like normal?
Does anybody have any suggestions?
WordPress uses XMLRPC to authenticate. You can, on top of the API given, write your own codes to store credentials. Persistent session can then be made.
Read this FAQ : XML-RPC Support for WordPress
Right now I am developing a Web-based Application, where the User has to login first.
When I open the Page by iPhone Safari, login and restart Safari, I am still logged in (Cookie & Session ID still set).
But when I add this Page with "Add to Home Screen", each Time i click the Icon for that page, I have to login again.
I did not find any information about that. What can I do so my users can set this page to their home screen
as icon and still don't have to login each time they open it?
A really simple approach could be to use a unique token in your Bookmark-URL which can serve you as a unique device identifier.
Example:
http://myWebApp.com/?token=randomId29238/1
The token can be generated at the server side at opening time of the application in Mobile Safari and before the user is prompted with the "Add to Home Screen" information.
The token can then be added to the URL using a quick redirect (…&token=randomToken) or a location hash (…#randomToken).
Whenever the Bookmark is now opened from the Home Screen, the token is sent to your server and you can identify the user's active session.
You may also use the token as a permanent session id, but I advise against that because of security concerns.
To allow future logout and login procedures, you can always assign the new sessions to the token.
The token will serve you as a unique device identifier whenever the user will re-open your link from his Home Screen.
There is an easier and, imo, more elegant solution than favo's.
At least under iOS 4.2.1, 5.1.1, 6.0 and 6.1 (I couldn't test other versions), if you extend the lifetime of your session cookie manually, Safari will hold on to the session cookie and even allow sharing of the session between the 'home screen installed' version of your web app and normal visits through Safari itself.
The trick is to do this:
// Start or resume session
session_start();
// Extend cookie life time by an amount of your liking
$cookieLifetime = 365 * 24 * 60 * 60; // A year in seconds
setcookie(session_name(),session_id(),time()+$cookieLifetime);
For a more elaborate discussion of this strategy you can take a look at my answer of this question:
Maintain PHP Session in web app on iPhone
I am going to expand a little further on Waldo Baggins' answer.
When I ran into this, I discovered the reason this was happening is that session cookies set on the server usually do not have an expiration value set. The default behavior in this case is for the browser to discard the cookie when the browser is closed / re-opened. Since the browser does not resend the cookie on re-opening, the server has no way of identifying the session, even if it hasn't expired on the server yet, and thus, your user is redirected back to the login page.
When the user is using your site in web app mode (icon added to home screen), iOS treats navigating to / from the app the same way a desktop computer would treat closing and reopening the browser, and loses the session when reopened.
So following Wilbo's suggestion and setting an expiration time for the cookie, iOS checks if the cookie has expired when the user navigates back to your app, and if it hasn't, re-sends the cookie, thus maintaining the session. The value of 1 year in Wilbo's answer is ridiculously long, you would typically want to set this to something like 8 or 24 hours, and ideally sync it with the session expiry timeout value you have set on the server.
Note that as a side effect, when your site is accessed from a desktop browser, and the user closes and re-opens the browser, the session would continue to persist and the user will still be logged in, which wouldn't have been the case previously (unless they were browsing privately). Your "Logout" feature would have to properly handle expiring this cookie.
For a Java webapp using web.xml version 3.0 or higher, the easiest way to do this is to modify <session-config> as follows:
<session-config>
<session-timeout>600</session-timeout> <!-- In minutes -->
<cookie-config>
<http-only>true</http-only>
<secure>true</secure>
<max-age>36000</max-age> <!-- In seconds -->
</cookie-config>
</session-config>
There are persistent key-value storage and database storage available for web apps. You can save your authentication data using localStorage object and use XMLHttpRequest to send it to the server.
Another option is saving your persistent data in a SQLite database, however this doesn’t seem to be a proper solution in your case.
Check out Apple’s Client-Side Storage and Offline Applications Programming Guide for details/examples.