I am creating a connection between a clients Shopify store and an order management system called Extenda NYCE. For this I have created a custom app and given it all necessary accesses via the Admin API congifurator.
When I've configured the app and installed it in Shopify backend I use the API keys to get access to it via the order management system, but I get an error. Due to poor UX I can't see the whole error message but basically what I am doing is I try to make an article import by using the API keys.
Now I've tried to find a solution to this by reading about using API keys and I seem always to end up in information regarding access tokens and the need of implementing access to these so that the third-party system can get access to the API.
I'm totally lost so I figured why not look it up with StackOverflow. Have you had similar experiences? To me it just seems way too advanced if I need to write scripts to generate access tokens so that the API can have access to the shop data. Isn't the API interface developed NOT to have the need of writing code in Shopify?
I want to build web app that uses Spotify API. I got case where user has to authenticate with his spotify account, then I recive access and refresh token that is being used in code to authenticate calls to Spotify to perform some actions on user's account.
I have trouble deciding how it should be really done. First thing that came to my mind - store them in Redis for some time, update on refresh and whenever we need to perform some action on any user we get his credentials and do it. Is this proper way? I tough about simply storing them in app memory but I might want to make in serverless.
Did anyone come accross that kind of problem? Do anyone know how to do it 'properly'.
I'm using Teamwork as a project management tool in my team. It is a great tool, but it ridiculously lacks some important functionality. For example, their reporting facility sucks.
Though, they have API using which I can build reports myself. API key is specific to the user, so using any given API key you get access of the owner of the key.
So, if I give my API key, anyones who has it, gets access to all infromation in Teamwork (including information under NDA). So giving my API is not an option.
Making an app where I need to put my API key manually is not an option too, as developer still can get access to this key (by simply recording all inputted keys).
So my question is: is there some way to make authorisation like the one facebook has for other sites for services where such kind of authorisation is not implemented?
I wish to create a functionality that is very similar to facebook or pokerstars if you have used them before. Basically the apps require the user to login and their information can be accessed from both browsers and native and web apps.
How can I go about achieving this? Please advice on what services to research on to accomplish this. To my current understanding. I would be creating the website in html and php and creating a webservice using RESTful protocols and hosting them on amazon aws servers. I can then connect to these servers in the native apps? I am not very clear on how the native apps will interact with the servers
If you know of any particular protocol or a better server hosting service please let me know.
If I'm interpreting your question correctly, you are looking for something like this:
The user starts either your browser app or your native app (perhaps a mobile app)
Since the user does not have an account yet, you present them with the appropriate dialog to create said account.
You then ask the "Identity Service" to create a profile for that user
The identity service returns a token for access
This is something we do in the mobile network industry all the time. Technically, we have TAC/ACS or HSS profile services, but in either case, it's the same thing -- a dedicated service and network process that:
Accepts connections from various clients (web, mobile, desktop...)
Has various primitives along the database CRUD (Create, Read, Update, Delete) model
Answers requests the database
If you want a pre-configured solution, you could just use any networked database with a RESTstyle connector for example (MongoDB maybe?) But you could also just through this in a process that talks to a NoSQL or SQLLite database. The end result is the same.
For commercial solutions, I might like at OpenStack as you can run your code on it and they have identity brokers you might be able to CoOpt.
Personally, I'd just have a datastore running on a cloud somewhere like Amazon's EC2 which answers RESTful requests such as:
Create a user with a given profile set, return a unique token
Delete a user given a token
Update elements of the profile for a given token
I'm leaving out the necessary things like security here, but you get the idea.
This also has the advantage that you can have a single identity service for all of your applications/application services. The specifics for a given application element are just sub-fields in the profile. This gives you, not only a common identity broker for web, desktop and mobile, but a single-sign-on for all your applications. The user signs in once and is authenticated for everything you have. Moving from site to site, now just became seamless.
Lastly, you place your identity management, backup, security token management, etc OUTSIDE of your application. If you later want to add Google Authenticator for second-factor authentication, you don't have to add it to every application you have.
I should also add that you don't want to keep the identity database on the direct internet connection point. Someone could make your life difficult and get ahold it later on. Rather, you want your identity server to have a private link to it. Then do something like this:
When the account is created, don't store passwords, store hashes -- much safer
Have your application (web or otherwise) compute a key as the login
In this case, the user might enter a username and password, but the application or website would convert it into a token. THAT is what you send across.
Next, using that token (and suitable security magic), use THAT as the owner key
Send that key to the datastore and retrieve any needed values
Encrypt them back into a blob with the token
Send the block
THe application decrypts the blob to get at values
Why do we do this?
First, if someone were to try to get at your identity database, there's nothing useful. It contains only opaque tokens for logins, and blobs of encrypted data. Go ahead -- take the database. We don't care.
Second, sniffing the transport gets an attacker nothing -- again, it's all encrypted blobs.
This means later on, when you have five applications using the broker, and someone hacks the network and steals the database, you don't care, because your users never gave out logins and passwords in the first place, and even if they did, the data itself is garbage to anyone without the user key.
Does this help?
I would like to programmatically query the Flickr API using my own credentials only just to grab some data from there on a frequent basis. It appears that the Flickr API is favouring OAuth now.
My question is: how should I authenticate the API without user intervention just for myself? Is it possible any more?
Once you have received an oauth_token (Access Token), you can use it for multiple subsequent API calls. You should be able to persist the token in a data store (I haven't done this myself) and use it even after your application restarts. Of course, you still need to write the code to get the Access Token the first time.
If your application is already coded using the old authentication API, it looks like there is a one-time call that you can make to get a new-style Access Token. See http://www.flickr.com/services/api/auth.oauth.html#transition
Even if you don't have a coded application, you might be able to use the API Explorer for any of the calls that requires authentication (flickr.activity.userComments, for example) to harvest an api_sig and auth_token.
The scenario which you are describing is sometimes referred to as 2-legged OAuth. (https://developers.google.com/identity/protocols/OAuth2ServiceAccount)
Google APIs support this via a 'service account'.
Unfortunately Flickr doesn't seem to support this kind of interaction.
For public data interaction (like downloading your public photos (photostream) from your account), there's no need to authenticate. You can get the data using only the Flickr user-id.
For other interactions (like downloading private photos (camera roll) from your account), you'll need to follow the full OAuth procedure at least once.