I'm currently working on a PWA and noticed that the overall experience would be awesome for the users, if they do not have to sign-in every time they open the app.
I've noticed that on native mobile apps, the user stays signed in unless they decide logging out of the app.
I could think about the following approaches -
Make the session time super long; say 30 days or 180 days. I'm not aware of the downsides of this approach.
Create a cookie that says that auto-login link and use it to authenticate the user automatically when they open the app.
But there could be a way better approach than this; and I'm curious to know about it. Can someone help?
Well depends on your current user session algorithm, websites like facebook keeps me logged in for years, you might want to use
Local storage (Indexed DB) to store the user's data only update them asynchronously ,
Cookies, set a (x months) cookie and validate the cookie if it exist probably with the user's data,
This would be preferably done with your server side language and not client side.
Related
Is it possible to limit the total number of user installs of a Facebook application using Facebook API or configuration?
Obviously the beauty of Facebook's platform is the virality. However, the greater the number of installations the more server demands grow etc.
So when building applications for clients with fixed budgets (think marketing activity / capping adverts per day based on spend) - is there a way to restrict the total number of users that Facebook allows to install an application?
Specifically talking here about building Facebook Games.
No, there is no build-in mechanism for that – because usually developers are happy about an ever-growing user base.
A canvas app is not really “installed”, users just connect to it. And this is the only point where you could try to handle this – once a user has connected to your app, you can recognize that (via the signed_request parameter or using the JS SDK) when he visits your app next time. So from a certain point on you could just not ask users for login any more (FB.login, redirecting them to the Auth dialog, …).
Obviously your initial app page will still be called, but any stuff you do afterwards with connected users and their data (if that’s what strains your little server most) you could just stop for users that are not already connected. Big downside of this is of course, if a user removes your app (willingly or by accident), they will find no way to re-connect with your app again.
Maybe you should consider hosting your app on a platform like Heroku – it’s free, and I think they will provide you with enough server power to handle your app growing larger than initially planned/expected.
I don't use either FaceBook or Twitter, so I am somewhat hampered here.
A friend is going on a once in a life-tine yacht journey and their will be a satellite modem which reports latitude/longitude (and some more data) data on a regular basis. This data gets stored in a database, to which I will have access.
My friend wants to Face/Tweet updates, hopefully with a Google Maps map. He doesn't want to give me his passwords as that would give me full access and let me read his private stuff.
I quite understand that, but what are my options? Obviously, the APIs to FaceTweet won't allow me to post without (his) credentials. Can I create accounts of my own and he can then configure his FaceTweet to say "anything that gets posted there, I want to post it on my site too"? Does Face/Tweet offer such a facility?
The alternative seems to be to code a desktop app to scan the database regularly and post new updates using his password which he must enter into the app, so the app must run on his home PC.
Of course, that is not perfect; if his home PC crashes when he is away then the updates will cease. If it runs on my server, then no problem, but he doesn't want to give me his password and lives too far away to come here and type it in himself.
Can anyone advise me as to how best to implement this? Thanks in advance.
For Facebook you will have to create an application with "Post on your behalf" permission.
Update:
For Twitter it's much trickier: you will have to deal with OAuth tokens to access someone's account after you ask user to authenticate. Here is a fine article on that. You will have to press some free PDF download on our members page and it will ask for you e-mail, but you can press cancel and it redirects you to article anyway.
I have seen many web apps supporting Facebook Connect...
But when i login through those apps sometimes the authentication is successful but nothing is returned to the app and the login page just goes to a blank page in that new windows and stops... The whole process fails... And this has not occurred once but many times...
So my question is:
Is Facebook Connect a good solution to use in apps or should i use something like Google Login or Twitter Login or OpenID or just a simple password based login or all of the things and let users choose what they want?
And if your answer is app the solutions then wont my database become messy and the app slower because it has look for more data now?
I know it depends on various factors but I just want your opinion, what would u choose and why?
Supporting Facebook connect as login function make sense only if your app has something to deal with Facebook (which is the most of our app today ;-)).
The behave of some app when sucessfully Authenticated and then Authorized is up to these app.
FB login give you all the tools to build you own user experience.
The things become a bit more difficult when you want to introduce FBConnect within already existing login base, while you have to find a way to bind the Identified FB user with your user account.
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.