I have a question regarding the login system. So let’s say that I’m building a website that requires from the users to login but I don’t want them to create an account only for my website. What I want to do instead is to log them in if they have an account to (let’s say ) the website X.
In short I want to use the login system of a second website X for users to enter my website. Is that possible in any way ?
You can use oauth if the website X implements it.
OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords.
Facebook, google and others let you log in with their systems through oauth.
Related
Having googled various iterations and looked at the Facebook info I'm none the wiser.
What I'm looking to do is have the ability to cross reference my business page on Facebook and where a user has Liked our page they can then login to our app, thus if they unlike us their account is disabled?
Basically having written a free app that could be widely used for what our business provides we get a simplified marketing strategy.
The app I have is built around jQuery Mobile and links to a MySQL database.
Would the user register an account with me and then Like us on Facebook for us to cross reference the FaceBook API's? or would I have to have full FaceBook login? Or even worse is this not possible?
I have a mobile application built with html 5. I've deployed the mobile application to iphone, android and blackberry using PhoneGap. The app loads up a list of user profiles via an Ajax call to my web server which has a database of user information.
My database of user information currently lacks user profile images for any of the users. How do I allow a user to associate their user profile on the mobile app with a profile image of themselves?
My current challenges are:
I can't seem to get html5 file upload button to work on the iPhone
a friend told me to try authenticating with linkedin, then ask for their linked in profile image. This can be done via of a concept of "childbrowser" on ios devices. But he claims there are some challenges (i think in terms of a good user experience) with android and blackberry?
Have you looked into Gravatar? Your users would have to set up their profile picture on the site, then they provide you a link to their chosen avatar from the Gravatar website. It doesn't require any authentication to use.
The iPhone browser lacks most of the file related APIs.
Anyway I have had enough problems with File APis to recommend the solution that #saluce is probably your best bet. Use a web service whenever possible to avoid having to deal with files as much as possible and for this particular use case, the gravatar solution is a good bet.
I am developing a login and account system for use with an existing website, this will run on a subdomain under the main site url.
I would like to use a subdomain that is generic enough so it isn't tied to an account system but not off-putting to users.
I was thinking of www2 but I am concerned people will see this and think its not "legitimate".
Thanks
Some more context.
The new site is currently used for the login and account system but I will eventually migrate the whole website to the new system, this means the services and pages served by the subdomain will very a lot so it can't be specific to one thing.
Try something generic in the interest / knowledge domain of the existing website. What does the existing website do or provide? This can help you determine a proper subdomain.
Some generic examples:
info.domain.com
account.domain.com
auth.domain.com
app.domain.com
to.domain.com
Providing a better subdomain is going to require some more context.
I'm looking for web applications that users can use without registration, just by visiting the site, and make you register later after you spent some time.
Any good examples?
Stack Overflow; question an answer sites.
Google News; blogs and newsfeeds.
Apple's iTunes Store, Amazon; anything where you have a shopping cart.
:-)
There's this site called StackOverflow.com
Sometimes when you are looking for example sites that you've seen in the past, it is just to increase your own confidence that you are doing it right. If you have a good idea of the advantages of this style of progressive registration, why not take a moment to write down & plan out how it should work for your site?
Edit content without registration (but create a pseudo-account using IP address):
wikipedia
Register with your email address, optionally password protect your account later:
http://www.instapaper.com/
Registration as a side effect of paying for a product
Amazon (if I remember correctly)
Not sure if the title is quite right for the question but I can't think of any other way to put it..
Suppose you wanted to create multiple different web apps, but you wanted a user who was logged into one app to be able to go straight to your other app without re-logging in (assuming they have perms to look at the other app as well). If I'm not mistaken, if you're logged into gmail you can go straight to your iGoogle, googleReader, etc without re-logging in (if you set it up right).
How would you approach this? What would you use? Assume the apps already exist and you don't want to change the initial login page for the users.
What you're looking for is called Single Sign On. If you follow the link you'll find several implementations.
Open ID as others have mentioned is not such a scheme as it requires a seperate login for each site. Open ID is merely a shared authentication system.
You would issue a cookie against foo.com, which would then be visible on app1.foo.com, app2.foo.com.
Each application can then use the cookie to access a centralised authentication system.
Try CAS it should provide the features you are looking for.
What you want is a single sign-on (SSO).
There are two approaches to solving this problem:
Roll your own implementation. In its most trivial form it can be implemented by the first site setting a cookie that holds the ticket for the logged on user and the second site verifying that ticket and accepting the logged on user. There are quite a lot of potential pitfalls here:
you have to protect yourself against information disclosure - make sure that the ticket does not contain the actual user credentials
you have to protect yourself against spoofing - a man in the middle stealing a valid ticket and impersonating one of your users
and others
Adopt a third party SSO mechanism. Google, Microsoft, Facebook and other big companies allow integrating with their identity providers, so that your users could log on to their website and they handle verification, ticket issuing and so on. There's also OpenID, which is an open protocol you can use to enable SSO on your site through virtually any identity provider that supports OpenID. The potential drawback here is that somebody else controls your access to your user identity and can limit the features you can offer and data you can mine for your users.
As mentioned you can use something like OpenId or similar to make the process simple. Otherwise if you roll your own you could use a cookie to store the login, then basically ALL applications must have an entry point that mimics the base url.
Google for example uses mail.google.com to as a pipline into Gmail which allows it to read a cookie stored with the google.com domain.