Is there a way to test whether a user is logged into Flattr?
The idea is to set up a "I'm-ready-to-donate-wall" that only Flattr users are allowed to pass. However, unlike a paywall, the user is not forced to click a flattr button; I just want to make sure that he's ready to flattr anything if he/she likes what he/she sees. I am not interested in his/her account credentials either.
Obviously, this is a thinly veiled scheme to get users to sign up to Flattr. I don't know whether this is a good or bad idea, but it might be worth a shot.
"The idea is to set up a "I'm-ready-to-donate-wall" that only Flattr users are allowed to pass."
Beware that, if I remember correctly, it was not accepted in the Flattr code of conduct. Maybe it has changed lately (I cannot find the reference of this) but check first with some Flattr people if you can legally do that.
You can use "login" to your site with the Flattr OAUTH 2 API.
So what you would do is to connect your site as an third part application to flattr and then let the users authenticate with their Flattr login
http://developers.flattr.net/v2/#authorization
The first time the users access use your site they have to allow your app access to their Flattr profile.
Moreover, you can authorize a user without gaining access to any non-public features. To get any special access you need to specify the scopes for which you want special access - specify no scopes and the only thing you get to know is that a specific user has a specific account on Flattr.com.
Related
I have a chatbot running on a site and I'd like to be able to integrate flattr into it. It's built in Node and has no front-end, it just uses an API to interact with the site.
I'd like to be able to do something like this
note: all commands for the bot begin with "!"
!flattr #username to flattr a user
I understand this would mean people who want to either receive or give flattr would have to create accounts
Just looking for some guidance as to how to start this.
Here's what I'm thinking I need to:
Create an application, get Client ID and Secret, go through Oauth flow and get Bearer token. Including the scope for flattr thing in this process
How long are your tokens set to expire? Should be I updating this token often?
Then I guess I would just need to use the flattr thing api endpoint? Is a user considered a 'thing' in your api? Is the :id for a thing secret or can it be public without harm?
Does a user know their id or can they easily find it? Or would I need to use the Users endpoint to get that info? And does that mean adding an additional scope?
This is my ideal situation. In the chat all Users setup a flattr account and can connect the bot to Flattr by doing:
!flattr addme [flattr username] (alternatively they could use flattr ID if accessible)
then like I mentioned above, they can just use !flattr #[username] and that's it
thanks!
You do need API credentials but the ‘flattr’ scope should be enough.
You need to solve three problems, identifying users, authenticating users and then flattring URL:s (because the Flattr system only works with URL:s).
The later is easy, the best thing would be if your application/site provided a profile page for each user.
Something like ‘http://example.com/user/francisc0'. You would then just call the /flattr endpoint with that URL.
The response of the URL would either have to contain something that Flattr could use to ID the Flattr user or
you would have to pass the user id along with the flattr request. Read up on auto submit URL:s.
But in short, an auto-submit URL looks like
https://flattr.com/submit/auto?fid=abc123&url=http%3A%2F%2Fexample.com%2Fuser%2Ffrancisc0
In order to identify your users they need to have unique usernames on the chat (or something else that is unique that you are able to lookup from a username). Each user would also have to tell your application what their flattr id is.
This can be as simple as a input field where the user manually adds their id or you could fetch it from the API (look at the /user endpoint).
Now in order to flattr an URL your application (api client) needs to be authenticated as a Flattr user. As the Flattr user that typed the command “!flattr #username”. So my suggestion is that when a user wants to enable the ability to flattr on the chat you perform an oauth authentication for them and save the access token (they never expire btw).
When the user types “!flattr #username” in the chat you retrieve the access token for that user from storage and then send the flattr request as that user.
That should be it.
I did something similar for IRC a few years back and it worked great so it should work for your use case too.
Pro tips: Avoid using the /thing endpoints as they will be deprecated very soon.
The api documentation isn’t really up to date but that is also something that is changing very soon.
The user objects will soon include an ‘idv3’ attribute, use that as the user id instead of ‘id’.
Source: am Flattr dev.
I'm working on an internal website for the company I work for. The website will be only available to company staff. We use Google Apps for Business, so we would like authentication to be done using our google accounts.
I've gone through 'google sign in' samples from here: https://developers.google.com/+/
It works, but the problem we run into is that it requires the user to sign up to Google+. This is a speed bump we would prefer not to have.
Are there any ways around this? Thanks.
It shouldn't be too hard to roll your own sign in using the lower levels of Oauth, eg 'email' scope. It's hard to give a more specific answer because it depends on your architecture (eg. are you predominantly server-side or client-side) and what kind of session do you want to create by the sign in process. For example, if you are client/REST based, you probably don't want any session at all as REST encourages statelessness. On the other hand, if you are more web based, serving static pages, you will want a session.
In simple terms, you will be doing something that generates an access token, and then processing that access token to determine the email address (or Google ID) of the person who created it. You will then establish some sort of session (eg. using session cookies) that identifies future requests from that user.
Feel free to add some more detail to your architecture and I'll try to finesse the answer.
For simple http servlet sessions, it will be something like.
User requests a protected page
servlet detects that there is no session and/or session has no authenticated user
servlet redirects to an Oauth page to request an access code. something like
https://accounts.google.com/o/oauth2/auth?redirect_uri=xxx&response_type=code&client_id=zz&approval_prompt=auto&scope=email
NB research the exact URL, don't rely on this to be exact
If the user isn't logged on, he'll be prompted; if he has multiple logins, he'll be prompted; if he hasn't yet granted email access, he'll be prompted. If none of these conditions are met (the normal case) he won't see anything.
Browser will redirect to the redirect_uri, carrying an access token (or an auth code if this is the first time the user has used the app)
Post the token to the Google userinfo endpoint, and you will receive a decode containing the email address
Store the email into a session object (or retrieve your own user object and store that)
redirect back to the originally requested page. You can use the OAuth state parameter to pass that around
et voila. all future page requests from that user will be within a session containing some user identification.
NB This is just an outline and I may even have missed a step. You will still need to do your own OAuth research.
Apparently not:
(..) if a Google user who has not upgraded to a Google+ account clicks
on the Sign in with Google+ button, the same consent dialog that opens
will take the user into an account upgrade flow.
Weirdly the docs for OAuth2 states:
Google+ Sign-In works for all users with a Google account, whether or
not they have upgraded to Google+.
Does anyone have clues about how to do this? I'm basically trying to replace the strategy for "Connect With Google" from OpenID to OAuth. The challenge is identifying an old user (user on Google open ID) when a user signs in under the new OAuth scheme.
I have a working implementation which relies on email address as the primary key, as the open ID strategy captures that. The problem is, I don't want to ask for email in the OAuth flow. The ideal value is simply Google user ID, but the Open ID strategy doesn't seem to capture that.
So I have open ID tokens like https://www.google.com/accounts/o8/id?id=AfSCwGQ4PUaidXSQddJugXKLqU5V0MrXFhJM6UHybPw and trying to understand if I could get a Google ID from that.
UPDATE: I explained here how I ended up doing this migration - http://softwareas.com/migrating-user-accounts-from-google-openid-to-google-oauth-to-google-plus
We don't have a strategy ready today that avoids the user seeing another approval page.
However, rather than attempt to do an OAuth1 based hybrid flow and have to add all that legacy code to your server, I'd suggest you simply correlate on email address and move to OAuth2 login. I'm assuming you're like the majority of sites that end up asking for email address because they usually want it for account recovery. Just make sure you get the email address from OpenId as one of the signed parameters.
Then use the userinfo.email scope and OAuth2 https://developers.google.com/accounts/docs/OAuth2Login and you should be able to migrate with less developer pain.
In addition, we're in the process of adding support for OpenIDConnect and it supports a parameter of login_hint so you'd add &login_hint=bob#gmail.com to your authorization URL and it will steer the approval to the right account. This is not documented right now but it may be useful for you to try it. The user's browser could be logged into Google with a number of accounts and you want to try to get the right one. Always check the email you get from the OAuth2 flow to make sure it matches since this is just a 'hint'.
Users will still have to re-authorize for OAuth2, but we have plans to skip this reauthorization in the future. The main point is to plan on using OAuth2 and we hope to deliver a seamless migration soon and you'll be on a supported protocol.
Google uses directed identifiers for OpenID that are unique per relying party and are explicitly designed to conceal any correlatable identifier for the user. So the short answer is, no there's no way to get a Google ID that corresponds with a given Google OpenID.
One option, however, might be to use Google's OpenID+OAuth Hybrid flow. This allows you to get an OAuth token as part of a normal OpenID flow, which could then be used to get the user's ID from the OAuth2 Login API, which you can then associate with their existing account. Once you've done that for all of your existing users, then switch to using the OAuth2 Login directly.
The trick, of course, with this approach is getting all of your users to login again so that you can send them through the new flow. That will come down to how long you're willing to wait to migrate accounts, and whether you're willing to prod existing users by emailing them and asking them to login again (similar to a forced password reset).
I'm trying to add a "share via twitter" link to our website. I'm aware of the standard http://twitter.com/home?status=TWEET method, and it works good enough for my purposes when the user is logged in to twitter already.
If, however, the user is not logged in, twitter displays the login form first (which is only reasonable). After the login, the home screen is displayed without the tweet content.
Am I missing something obvious, or is this a know flaw in this method? If so, what is the easiest way (apart from using services like TweetMeme, which I noticed asks for login in advance) to make the share button work as expected?
If the user is not signed in when accessing http://twitter.com/home?status=TWEET it seems that the status is indeed forgotten. This would be a Twitter website issue and not something you're doing wrong.
Update: Use this URL instead: http://twitter.com/intent/tweet?text=TWEET
TweetMeme, on the other hand, uses its own Twitter "application" via the OAuth authentication, requiring users to log in before retweeting using TweetMeme, and is smart enough to include the tweet message in the OAuth callback URL so that it's not forgotten.
So really, you can:
Use TweetMeme, where the user would have to log in, but at least have the tweet be remembered once that's done;
Create your own Twitter application that uses the same tweeting functionality as TweetMeme; or
Use Twitter.com's less-than-desirable status updater and hope the user is logged in, or hope that they're smart enough to click the back button a couple times and click on your link again if needed.
Just use the following url and parameters
http://twitter.com/share?text=YOUR-TEXT&url=YOUR-URL
Then it works.
I'd like to be able to give my users the ability to display their recent tweets on their profile on my website.
I have a PHP twitter wrapper and understand how to make API calls etc, but I'm just wondering how to manage the user information.
What is the best practice here? I want them to be able to enter their credentials once, but I would imagine storing everyones username/password myself isn't the best way to go about it.
Is there a way to make an authenticated call once, and have twitter remember it?
Should I store the usernames/passwords and then just make a call when displaying the tweets?
Any advice here would be great.
Thank you,
Use OAuth, no need to ask users for their passwords:
http://apiwiki.twitter.com/Authentication
I think everyone would/should probably agree that storing the twitter usernames/passwords is bad, I can't believe they ever created a situation where you needed it.
You should never store unencrypted credentials of any kind. If your solution involves holding onto a plaintext password, even for a brief time, you need to rework something.
Absolute best practice would be to hold no information yourself - use cookies or OAuth to handle your authentication. A session token or cookie can be disabled by the user at will, giving them control over the behavior of your site.
Next best thing (although still pretty undesirable) would be to hold non-reversibly encrypted credentials to resend to Twitter whenever you need to display tweets.
You don't need their passwords to pull their latest tweets, unless their profiles are locked, simply pull the feed from http://twitter.com/statuses/user_timeline/username.rss
You should look at Twitter's OAUTH support (although they have disabled it). This enables you to prompt the users once, and then store a response from twitter which will allow you to post
Tweets that you would want up on your web site are generally public anyway.
If you did need to authenticate somewhere (perhaps allow users to send new tweets) on a user's behalf, the best practice is to prompt the user at the time you initially authenticate and then store whatever authentication token is returned by the resource rather than the credentials used to get it.