I am using laravel to build an app in BigCommerce. I am able to get access token but I need to store that for future requests. What is the best possible way to store the app data for BigCommerce?
I've got this working by creating a DB schema in Laravel where in there are tables like stores, users, app_settings.
Whenever the user installs an app, I am storing an access token and other information like store hash in stores table and user details in users table.
Whenever the app is loaded I could get the store and user information via verify signed request payload. Using this I am able to configure my app settings for the user and store those in app settings table.
So when I create a Webhook for the store, I could get the store hash from response as producer key and accordingly I can find the access token for the store using store hash in stores table.
If you're git ignoring your config.json or .env files, you could store these there. However after speaking with one of our Developer Advocates, I wanted to pass along some best practice advice. :) You may want to consider using a secrets manager for option #1 in your decision here. A secrets manager meaning a tool to safely store these variables like Secrets in Github or Key Vault in Azure.
Also, this resource may be helpful to review for your use case. https://www.codementor.io/#ccornutt/keeping-credentials-secure-in-php-kvcbrk55z
Related
Is it possible to disable requests sent to Parse without a master key? I'd like to only access Parse through my custom backend and not give users direct access. Does public 'read' set on the User class mean that anyone can read the records in that class? If so, why is this a default - wouldn't that be against good security practices?
Thanks,
Daniel
Public read means that anyone with your api key can read the user collection from your parse server. Api key is not the best approach to protect your app because anybody can know it by putting "sniffing" your network requests.
In order to protect and provide access you can protect your objects with ACL's which allows you to create access for specific user (who is logged in) or to specific role. So you have couple of options:
Create a master user - each user must have username and password and when you create your parse objects make sure that only this specific user create/read/delete and update them. You must only to make sure that when you create an object you create ACL for this user so only this user will be able to modify and read the object. You can read more about parse-server security and ACL's in here: http://docs.parseplatform.org/rest/guide/#security
Using parse cloud code - In cloud code there is a nice feature of useMasterKey which provide full access to any object of parse-server so for each operation that you run (via JS SDK) you can also set the useMasterKey to true and then parse-server will ignore all the ACL's and will execute the query for you. The useMasterKey feature work only in cloud code context so it's safe. If you want to provide additional level of security you can run the cloud code function with your master user (from section 1) and check inside the cloud code for the user session so if the session is empty then you can return an error.
You can read more about cloud code in here: http://docs.parseplatform.org/cloudcode/guide/
This is the code which validate the user session:
if (!request.user || !request.user.get("sessionToken")) {
response.error("only logged in users are allowed to use this service");
return;
}
I would like to bring a login with Github and Facebook to my single page web app, the server is under my control.
In this tutorial
https://spring.io/guides/tutorials/spring-boot-oauth2/
they store the client_id and client_secret in a file.
Wouldn't it be more convenient if I stored these 2 in my backend database ?
Let's say someone who's not a programmer would like to register the web app to a new service , he could do that easily opening the database, he doesn't have to crawl into the backend project code.
If not then where should these 2 be stored ?
If you talk about the convenience, storing these in a property file is a good option. By doing so, the properties can be easily loaded into the application during the startup. If you change the values, all you need to do is just restart the app and the new values will be reflected.
I am not sure I understand your non-programmer related comment 100%. But IMO, for a non-programmer, modifying a file is much easier than modifying the DB.
Just to be more clear, the client id and the client secret represents the credentials of your application registered with the social media (like facebook).
Ans yes, you can store these in DB as well. But then, you need to write code to fetch these values from the DB and load into your application.
I'm designing an app that counts on accessing multiple API's that need the certain users credentials which are provided when a user allows access via OAuth. I'm new to designing programs like this and I'm trying to wrap my head around the easiest way to do this. Here is what I was thinking:
During the Oauth process I specify the callback url (lets call it A)
Create a POST route for url A that points to a function in the user controller
That function then parses the JSON data with the API Key+Secret, hashes the data, and stores it in a column of the user table.
Would this be the best way to go about this?
One thing I'll say is don't tie these directly to your users. Sometimes users may want to authorize multiple accounts, and sometimes multiple users may authorize the same account. Since you can only have one active refresh token per oauth account, these creds should be kept in a separate table and then linked with a many-to-many for flexibility
I have an app that uses parse.com as backend.
If I want to store information about user's in-app purchases in table there, how can I be sure that some guy is not going to create a simple app where users of my app can log (like in my own) in and write in parse-tables whatever they want (for ex.: that they made in-apps when they really didn't). This info is used to give the user access to app's features so it's important that the user really paid for that.
Don't make the table name public knowledge, so don't ever access it directly from the app, always use cloud code. Pass the cloud code some salted hashed details to verify against, and do the verification on save of any new objects being added toot that table with a before save hook. Drop any new objects which don't pass the test.
I just started looking into OAuth and it looks really nice. I have oauth with twitter working in ruby right now.
Now I'm wondering, what is the recommended safe way to store the responses in my local database and session?
What should I store?
Where should I store it?
This example twitter-oauth-with-rails app stores a user.id in the session, and the user table has the token and secret. But that seems like it'd be really easy to hack and get the secret by just passing in a slew of test user ids, no?
The tokens are useless without the consumer key/secret of your twitter app as they're not the same for every app but depend on the consumer key/secret.
To get a session variable you would have to guess the session id which is not that easy to accomplish.
If you want you can store those tokens in the session but I would suggest storing the user tokens in your database with all the other user data so your session contains only the data to identify the user in your system.
Update: I'm not sure if I understand correctly what you mean by accessing the tokens from the database by guessing an ID.
Do you have any authentication in place so that the users have to enter some credentials to access their data? You should store the tokens the same way you store the users email address or password and only authenticated users should be able to access it.
If you're developing a web application you can add a hidden field to the form the user submits, with some hash-like value calculated with the user.id so evil guys cannot change that value and just "guess" for an access token