I created a shopify app using the shopify node app template: https://github.com/Shopify/shopify-app-template-node. I haven't modified much of the template yet.
I want to be able to make eBay api calls in my shopify app but I need to incorporate eBay's oauth flow to do so. To do that, I need to set up a redirect url in my ebay dev account. This is the url that eBay will send the access token to (in the query params) after the user logs in on the oauth page. In my shopify app, I can easily redirect the user to the eBay oauth page for them to sign in, but how can I allow my shopify app to be called by eBay so they can send me the token?
I've tried using the "shareable app url" which gets generated after running 'npm run dev' as the ebay oauth redirect url and setting up an endpoint in my shopify app (in web/index.js) such as /ebay/auth/accepted. But eBay doesn't seem to be able to reach my endpoint.
I also just tried entering this url/endpoint in the address bar directly and am not able to reach it. It seems that whichever authentication mechanism the app template has built-in is preventing external applications from making calls to my app. How would I allow eBay to call my app using this shopify node app template?
I used to do this by peeking into the App callbacks. So we set /auth/shopify/callback and what I noticed is the the router interpolates the shopify aspect there. So if you set /auth/ebay/callback to get their token, in the callback in the App, you'd stop assuming you only get shopify, and now start checking for either shopify or ebay. So I had my router let me know: your mileage may vary of course, but that is all it was, and probably still is.
get '/auth/:provider/callback' do
case params[:provider]
token = request.env['omniauth.auth']['credentials']['token']
when 'shopify'
# save shopify record
when 'ebay'
# save ebay record
end
# ... lalalala do whatever.
Related
I’m working on a Slack app that a user can install to a workspace using Slack’s Oauth flow. After installing and configuring the app, I’m using Oauth to allow the user to log in and make changes to the app configuration.
The flow for a new user uses the "Add to Slack" button which asks the user to agree to allow bot and identity.* scopes after which my app retrieves and stores bot and user tokens.
Now I'd like to allow the same user to sign in using the "Sign in with Slack" Oauth flow. Per the Slack documentation, the "Sign in with Slack" flow allows just this using the same /oauth/authorize endpoint, but requests only one of the identity.* scopes (I'm using identity.basic):
Sign in with Slack
The user has already authorized my app for bot and identity.* scopes on the initial app install, but surprisingly he/she is re-prompted to confirm allowing my app identity.* scopes on each "Log in with Slack" action.
The slack documentation implies that subsequent login attempts will result in an automatic redirect:
After a user clicks your Sign in with Slack button, their web browser should arrive on Slack's servers.
Your application will wait patiently while the user handles some business or Slack just sends them on their way back to your redirect URL.
(emphasis mine)
However, Slack always requests that the user (re-)authorize my app for identity.* scopes. How can I log users in using Slack with a one-click flow?
Update: Response from Slack
I reached out to the Slack team and got this response:
Unfortunately it looks like we'll need to update the documentation as for the moment what's described there is not accurate. Particularly:
Returning users won’t be distracted by unnecessary approvals, we’ll send them back to your site, service, or app as fast as we can!
Due to a change we made to our authentication flow where we now allow users to select what workspace they're authing with, we present them with the "scopes" or "permissions" page again.
This is definitely something we should consider make better but for the time being it's the expected behaviour and we're going to revise the documentation to eflect that.
Sorry for the bad news.
As of 11/17/19 the Sign in with Slack documentation has not been updated.
For your requirement to implement a web page that is linked to your Slack app with authenticated Slack user you have two alternatives:
Sign-in with Slack
One approach would be to use Sign-in with Slack to authenticate users for your web page. This allows you to clearly authenticate users. However, the drawback is that users would have to repeat the login process every time they open this web page again. This can be somewhat mitigated by using cookies to keep users logged in between browser restarts until they manually log out of the web app.
Note that this auth process is independent from the user logging into his Slack workspace.
Own authentication
Alternatively you can let users directly open your web app from Slack, e.g. by clicking a link button you provide. This URL needs to include information that would allow your web app to get the users current context, e.g. his Slack and User ID.
Note that this URL can be obtainable and potentially misused by a user, so you would need to add measure to protect it e.g. by encrypting the IDs or by adding a secure hash or a one time token ...
I am developing one application which uses the youtube-data-api. I know it must be use with UI but I want to use it with predefined my own user credentials with back functionality in Curl or any php programming.
So I want like on one click my app should automatically get the auth access code without UI which is based on just a web server link calling from application back-end.
Can you please help to sort out my issue?
The problem you are going to have with this is that YouTube API doesn't not support service accounts.
You are going to have to use Oauth2 and authenticate your application once. Save the refresh token then use the refresh token to access the account later from your back end application.
You will have to keep an eye on it refresh tokens don't expire often but on rare cases they can expire you will need to authenticate it again if it does.
I was just wondering if there was a simple function to create a customer in the Stripe API from my app in Swift? Instead of having to create a manual HTTP post request to my server, "createCustomer.php", and then retrieve the results (This is what I do right now).
I tried to search this up on Google, but I can't seem to find anything. I simply want the user to save their card details for later user, that's why I am in need of creating a customer.
Thanks in advance!
Except for payment information tokenization (which is done via Stripe's iOS or Android SDKs in mobile apps, and Checkout or Stripe.js in web apps), all API requests must be sent from a backend server.
The reason is that aside from token creation, all other API requests must be sent using your secret API key. You cannot embed or share the secret API key with your mobile app in any way, as it would then be possible for an attacker to retrieve it and use it to issue API requests on your behalf.
This is why there is no Swift function to create a customer -- the customer creation must be done from your backend, using the server-side language of your choice.
I have developed a PHP website where users authenticate via Facebook and I get and store their auth_token.
On the other side, I have started developing an iOS app where users will be able to authenticate via Facebook too. The auth_token, as you know, will be different from the one that I got in the website auth process (same Facebook app as in the website)
My question is: can I use the auth_token that I got in the iOS app to make requests from the website? (same user, same app)
The reason is that sometimes I want some actions to be performed from the mobile device (ie. update status) while others to be performed from the web server (ie. checking which friends of the current user are already registered in my website)
thanks
Essentially, as long as you have a valid access_token for the specific user you can use it anywhere you want. Anywhere that you can execute an http request to Facebook and provide the correct parameters, you'll be able to make API calls on behalf of the user.
https://graph.facebook.com/USER_ID?access_token=XXX
This call should work regardless of where you execute it from.
I asked various questions about my problem (here and here) and I also asked in the #oauth & #openid freenode's channel on IRC. (this is note an "UP" question, it's an other problem)
I'll sum up my project configuration : Anyone will have the possibility to create an app that can use my API. To start, I'll work on my API and a Web based app, but the documentation about the API will be public. It's a bit like Twitter API.
The problem I face is how can I be sure which user is using the API (to retrieve his personal data, like your tweets), even if the User is using an app that I don't know who make it (again, like twitter and all the apps around).
I googled a lot and with the help of the previous answers given, I took a look at OAuth.
As far as I understood the way OAuth works, here how :
A user visit an app that use my API (web, mobile, whatever)
The apps redirect the user to the API for the authentication (I'll use OpenId) and the authorization (OAuth). This is a bit odd since the API will have a web interface for the login and the authorization (I suppose this is how it works since Twitter do that)
The API redirect the connected user to the app, with some tokens. In these tokens, there is a token representing the user that the app must store in order to indicate to the API which user is using it currently (Am I correct?)
So far, everything goes well. But what I can't figure it out, is when the user quit the app and goes again : how the app can remember the user is the one that used it before ?
(Before some of you bring me the cookie answer, I'll remark this is a simple example, it would be the same if the user clear his cookies, format his computer or change its computer.)
The only solution I can find, is when an unauthenticated user (without a remembering cookie for example) goes to the app, the app redirect him again to the API to authenticate himself, but this time, the user won't have to re-allow the app (authorization) since it already did it. The API will then return the user to the app to allow him to play with this.
Is this the proper & secure way to do it ?
The #OAuth IRC channel told me about the new protocol, WebID, but this is currently in pre-draft mode and I don't want to use something that will change continuously in the future :/
Thank you very much for your help!
Short answer: OAuth results in an authenticated access token. That access token is tied to ONE user. And as long as the access token is valid. The third application can do whatever the API allows the access token to do.
Long answer:
The thing with OAuth is that it does not "Log in" a user. OAuth gives third party applications what is called access tokens which can be used to access data on behalf of a user whether he/she is logged in or not.
Many services restrict their access tokens. Twitter for example issues two types of access tokens, read-only, and read/write. But there is no concept of logging in to use APIs. While an access token is valid, a third party application can access the user's data, and change things without a user's explicit interaction.
Most API providers have functionality to revoke access tokens. That is what happens when you in twitter look at your Connections page . See the revoke access links?
Personally I love the OAuth approach. As an API provider, you can control what access tokens are allowed to do, and the user can kill bad applications from using his/her resources. OAuth is secure as far as authentication goes. Third party applications do not get hold of user's passwords. But once authenticated they can do whatever your API allows.
if we take a look at how Twitter works, I think the missing point is an other layer to the project: The Official website:
The thing is, when you want to allow any 3rd party application to use Twitter, this application redirect you to the OAuth page of the Twitter API, IF you are connected, but if you aren't, it redirect you to the login page, which is located at http://api.twitter.com/login
(I don't know if keeping the api in api.twitter.com for loging an user, instead of just twitter.com is correct, but this is just semantics)
So, the workflow would be:
A user goes to a 3rd party application (like a website)
This third party redirect the user to the API for Authorization
The API redirect the User to the website for Authentication first
The official website redirect the User to the OpenId provider (or Facebook connect)
The Authentication is made (via multiple requests)
The website redirect the user to the API after he's successfully authenticated
The user allow/disallow the permissions asked by the 3rd party apps
The API returns to the 3rd party apps.
The User can now use (or not) the application.
This implementation have 2 problems:
Every time an User ins't authenticated (cleared it's cookies, connect himself from an other computer, etc), he will have to go through the Authentication method, by being redirected to the Official website and then being redirected to the 3rd party application (the API would be transparent, since it has already allowed the application to access his data).
All those layers would certainly lost the User on the Authentication process with too many redirections.
A possible solution would be to store the user's access_token, for example in the case of a mobile app, but with a pure html/css/js oriented app, this isn't possible. A login/password in the 3rd party web application that would match the user to the access_token of the API would be an other solution, like Seesmic (I think), but this is just useless (for us, not Seesmic) : the idea of not having the user's password become useless.
This is a possible explanation but I would require more details on how this is possible and your thought about that solution. Would it work?
(I added this as an answer since it's an (incomplete and not so sure, I agree) one.