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.
Related
I have an account that I do referrals on and instead of having to make an entire landing page, and provide users with my referral link - I'll just have them purchase from my account.
Is there any way I could generate a link that will automatically log users in without me having to reveal my password?
You could definitely do this by using something like a JSON Web Token (JWT).
Basically, the way it works is like this:
On your server, you create a JWT that is signed with a secret key (some random string that only your server knows).
In your JWT, you include your user's account ID that you want the purchase to come from.
You email this JWT to the person in a link, something like https://mywebsite.com/order?token=<jwt-token-here>.
The user clicks that link.
Your web server takes the token out of the URL parameters, and ensures it is valid (that the signature is good).
Your web server then finds the account ID in the token, and retrieves that user account from your user database.
You then LOG that user in using cookies or whatever, and direct them to the purchase page fully logged in!
This is a pretty typical web flow for what you're trying to do, and is a totally fine way to do things like this. There are tons of JWT libraries out there that make this easy to do, so it shouldn't be very technically challenging.
The only other thing you should know in regards to creating JWTs, is that you can set an 'expiration' time. You should DEFINITELY do this, as you don't want someone to be able to log in using your token months in the future. The best way to do it would to likely be generate a token that lasts for 24 hours or so, then email THAT to the user. This way, it expires after one day.
Last thing to know: there are actually quite a few auth libraries that simplify this stuff. I'm the author of one, myself: express-stormpath. Depending on what you're trying to do, that might actually make your life wayyy easier as it can generate those tokens automatically, and handle session creations for ya.
Hope that helps!
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+.
So, I have my web app connected with Foursquare API up and running. It has it's own secret keys and everything. It listens to the incoming push notifications and trying to react on connected users's checkins. So far so good, however, when I'm trying to post something back on user's checkin via one of these:
checkins/reply
checkins/addpost
checkins/addcomment
I got 403 Forbidden error. I know, that I'm messed up something with OAuth tokens but I'm really stuck here and feel a bit puzzled. I try to summarize what's the current status and what I've tried so far:
I Have the App's: clientId, clientSecret, pushSecret
I also connected the Foursquare Account on which the app is creared into my web App, so I get the accessToken, let's name it: appAccessToken
Users are getting registered to my web app, so I get userAccessToken for one of each.
And here we go:
Trying to reply for a user's checkin fails when I'm using appAccessToken. From what I understand, it's like replying on behalf on my App's account, and since that account isn't on the user's "friend list", I get 403.
On the other hand, I'm able to post reply when I use userAccessToken but then, It looks like the user is commenting itself on their own checkins which dosn't have much sense.
I was even so desperate that tried to use clientSecret but no avail...
Can anyone point me out what am I doing wrong here? From what I understand from the Documentation it is, in fact, possible to reply as an App... The only question is, how? :-)
There's ostensibly no difference between the two "types" of access token you describe: appAccessToken and userAccessToken are really two instances of the same thing (a user's access token), one just happens to be associated with the user account that created the app.
For each check-in you are pushed, you should use that user's access token when making a call to checkins/reply. This will reply to the check-in in the style of our Apps Platform. I think in your second comment, you're using the user's access token to add a post to the check-in, which will make it look like the user is commenting on their own check-in.
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).
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.