I like the idea of OpenID, I really do. But few of my target users have even heard of it - yet. If I want to offer OpenID as an option, my only choice would seem to come down to offering BOTH email/password authentication AND OpenID.
I've seen several sites that use this combination and the idea seems unappealing to put it mildly. Placing both options on the same screen is distracting and pointless if only 10% of users will even care about OpenID.
So I'm wondering, how could I offer a single user interface that supports BOTH OpenID and email/password for authentication and account creation?
One possibility I've been considering is to use a single OpenID/email field that can detect whether an email or OpenID was used and then dynamically adjust the interface accordingly.
For example, an account creation page might start off with a single field labelled "email" with some unobtrusive text along the lines of "we support OpenID". If a user enters a url, then the interface switches to an OpenID account creation page (via JavaScript). If an email address is entered, nothing happens.
What's the best method you've seen for hiding OpenID from the average user, but at the same time letting tech-savvy users know that your site supports it?
I think the way Uservoice combines username+password with OpenID is elegant.
That said, I disagree with the argument of not using OpenID merely because few people have heard of it. If you offer a few login buttons like "Login with Google" and "Login with Yahoo" alongside your "or, create a new username and password for yourself", then you don't even have to mention OpenID, and yet most users will likely pick the more convenient (OpenID) option without even realizing what they're using (and that's good!)
Decided to do some checking around on my own. Turns out there's a much better idea out there. The term seems to be 'OpenID selector'.
There's a free JavaScript library called JavaScript OpenID selector that makes it easy to create this sort of thing:
alt text http://img9.imageshack.us/img9/1940/step1c.png
This article explains the main problem and the solution:
One of the key results of Yahoo's OpenID usability study was that users did not understand OpenID and what its logo stands for. Instead, Yahoo promoted the idea of giving users a sign-in button that simply said "Sign In with a Yahoo! ID" (though Chris Messina argues that this could be detrimental to OpenID in the long run).Google and its partners are taking a similar route and are basically bypassing any mention of OpenID itself in favor of a simple message saying "Sign in with a Google Account."
There's even a sample Rails application that rolls authlogic, openid, and the selector into a single package so you can see how everything fits together.
See how SO here does it. That's a good a example, I like your idea of adapting the system by entered email as well, this is a trick facebook uses to send out facebook invitations to other people in your address book.
Would something like the following work?
Link to Login Page.
Now this site is running DNN and obviously it could be redesigned to be friendlier for the users. But the key here is that the standard way to sign-in is presented as the default sign-in.
I would probably redesign that site's interface to put LiveID and OpenID in a border labeled with Alternative Login Methods (along with a button for more help on how to use them) as well as change the buttons to read Sign In Using LiveID and Sign in Using OpenID.
Related
I am trying to understand what Apple is imposing as its new policy to ask developers to use Apple's own authentication mechanism.
Apparently Apple is using a different method compared to other authorization providers, such as Facebook and Google.
Apple's approach is, you receive the name and email at first login (say sign in). And after that you only receive a user id (something like 001134.432857YEASUREe274bxy231b3.0884 which means nothing unless you save it along with email and user name at the sign up).
Up to now everything seems fine.
The part that makes me confused starts here.
According to GDPR, as far as I know, you have to provide users a right to delete all their data from your servers.
And in this case, once we delete a user's all data then the correlation between "email+fullname vs user id" is lost for ever.
If the same user decides to reactivate herself, this time Apple will not send you email+fullname and this will impact the user experience.
Is my understanding correct? What is the solution for this problem?
References:
https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api/authenticating_users_with_sign_in_with_apple
https://developer.apple.com/documentation/sign_in_with_apple/sign_in_with_apple_rest_api/verifying_a_user
https://docs.expo.io/versions/latest/sdk/apple-authentication/
I am working with a research group that needs to collect Facebook post data for a group of participants over the course of a few months. The goal is let the participants authorize us to collect this information via facebook, and when they post to Facebook, send that information to a secured server.
After reading the Facebook documentation, I'm mostly just confused about how to provide a mechanism for the user to agree to the terms of collecting his/her data. I'm planning on using webhooks to collect the data, which is independent of the client platform, but do I really need to build separate apps for web, iOS and Android just for the approval process?
I'm planning on using webhooks to collect the data, which is independent of the client platform, but do I really need to build separate apps for web, iOS and Android just for the approval process?
You most likely won't get this approved in review anyway.
Permissions must, for the most part, be used to provide a direct benefit to the in-app user experience; collecting data for analytical measures only is explicitly mentioned as a not allowed use case. Whether the users would agree is not relevant here.
For example, user_posts permission, has "non-visible use of this data such as sentiment analysis or guarding against spam bots" marked with a red "X" for nope.
So the only way of getting your app to request the necessary permission(s) from users, would be to add them as testers to the app via app dashboard/API. Anyone with a role in the app which can be asked for any permission, reviewed or not. Those users would however have to have their accounts verified (mobile/text, credit card) and sign up as a "developer" on the FB platform, before your app could send them requests to become testers.
You'd be flying under the radar with that, so to speak. Facebook offers this "loophole" mainly for the purpose of letting developers test and develop their apps properly, before review. It is also explicitly mentioned in the app development FAQ as a way around the need for review, for specific use cases such as wanting to get your blog posts published to your own FB page automatically. It would not cover what you are trying to do so, but it will likely "work" as long as none of your test users specifically raises a complaint with Facebook ...
Not sure if there is any published limit on the number of test users that can be added to an app, people have asked about that in the past, but AFAIK none is documented or otherwise published by Facebook. If there is one, and it is not completely stopping this approach dead in it's tracks (say, a few hundred per app rather than, five), you could use multiple app ids, if you don't need to relate data between user accounts too much - because the app-scoped user ids will be different per app id, so that could making connections between friends that are in different "app-id test groups" etc. difficult. Or you might have to refer to other, less reliable measures of uniquely identifying them, such as email or profile name.
I have built a site and have several social networks to promote it, and sometimes I have giveways to people which I normally have through facebook. The giveaways normally require that the person subscribe to something (as a counterpart of receiving the giveaway or participating on trying to win it), but facebook and other sites just are bad for these kind of things, specially proving that you subscribed to anything.
So here's my thought:
Use a fillout template (like a HTML FORM)
person login with a FACEBOOK Account
Based on that Facebook account, person subscribes to
newsletter, likes a page, whatever, but everything done through that
FORM-like thing, logged in, one step to participate.
In your experience, is this even possible? with what? CSS, HTML, JSQUERY...
This time I'm opened to anything you can guide me, I'm tired of trying to work
giveways through social networking site's GUIs is just annoying...
Thanks for all the help you can provide.
Alban
Sounds like you want Oauth and OpenId. It's not particularly easy to set up, but it's very effective. If you sign into stackoverflow using google you're probably using it.
According to wikipedia facebook no longer support it, using facebook connect instead, but almost everything else does.
I'm currently writing a twitter client using javascript, then found out many people reminded javascript developers about not revealing "consumer secret". But they never said why.
So why is it so important to hide my consumer_secret? If anyone want to show my "via My_App" on his app, making the name My_App more famous, why should I worried about anything? After all, you can't get any useful information out of my consumer_secret, the user information is protected by both https and token_secret.
A malicious developer could create a spam application using your consumer secret. If enough spam accounts are using the spam app Twitter may disable the entire consumer key at which point your entire application will no longer work with Twitter.
You can think of the consumer secret as a password -- it identifies your client to the server. Anyone with your consumer secret can pretend to be your app.
So you need to keep it secure, and you don't want to "hide" it; you want to encrypt it. This should happen on the server, never in the javascript app that you send to the user.
You can find a lot of helpful information at Google's support page.
I have a donation form which users fill out and I would like to then send the user to the charities own website with their information already filled in. Is this possible?
thanks
This is a big part of what my company does....but we have to rely on the client as well. It could be a great exercise for both you and them.
Here's the basic idea. We take a web form entry from a site. We have a script that processes the information and decides where to route the info (we do this for quite a few different clients) Then the system goes through logic for each individual site (functions in a class) that tells it how to pass the information over. In some cases, it's simply an email to a person. In other cases, we CURL a string over that the recipient site has been setup to accept. One site allows us to directly post to a "hidden" page on their site....this doesn't seem the most secure option to me, though. The key is to negotiate with the partner how they'd like to receive the information. If you're helping them get donors, I suspect they'll be willing to do anything they can to help.
Be aware, there could be some security issues with trying to forward donation information across sites....you'll want to remain as secure as humanly possible....and personally, I don't think I'd ever transmit something like a credit card number except to a processor via SSL.
I was a non-profit webmaster for quite a few years, and still have several non-profit sites I consult with. There's systems out there just for this purpose (one that comes to mind is network for good) Also, I've seen groups build non-profits specifically to accept donations on behalf of other non-profits. Point being, there's many different ways to approach this task, not all of them even code related.