I have a simple ToDo app written in ReactJS with Express backend and MySQL. I've recently implemented Auth0 authentication, and the app successfully requires authentication before allowing a user to view or add tasks. Any user can see all the tasks (stored in DB), but at least authentication is required first.
Next, I want ensure that users can see only their OWN tasks. Can anyone either describe how this works, or share any decent resources on the subject? Any examples I can review somewhere? I imagine there is probably an ID value I can fetch from Auth0 user DB and silently include that as a column in the DB, then allow users to only fetch tasks matching their own ID.
Any resources appreciated.
Related
I was asked by a potential client if I can have my software interact with Esri/ArcGIS Online.
Use case: users is logged into SomeRandomSoftwareApp and is looking at a Widget, this Widget includes an Esri asset id, the user clicks a link that passes that ID to Esri/ArcGIS Online and behind the scenes the user is logged into Esri and they see the data associated with the Esri/ArcGIS Online.
Thanks, Keith
If I understand correctly, you have two options for this: API Keys or Application Credentials.
The first one, is a permanent token generated by the owner of the data that will allow the application easy access to it. This is still in beta, and it was not ready for use the last time I check some time ago.
The second one, the owner of the data will generate credentials for your application. With this credentials you will have to request a token each time you want to access the data, all this via OAuth 2.0.
Check the docs for more details ArcGIS Services - Security
Here is what I am planning to to for keeping separate tokens for web and mobile
1.When user is logged in from web JWT token is issued and it is stored in DB table with created time stamp.
The above step is repeated for the mobile client ,so the table contains separate tokens for each client.
2.At the time of validation search for the token in table and validate if exists then it will try to verify with JWT.verify
Is it right method to do keeping separate logins using JWT??
Maybe there are other ways to do it, but your approach is totally correct. By fact I would recommend it exactly your way. What you doing, is scoping issued token for specific service, platform. It is useful not only for your use case, but also when you have multiple APIs. You can issue different tokens for each service separately.
I have followed the instructions of Yii2-user documentation using the advanced template, but can't be able to signup frontend users and backend users on the same server.
Investigating the structure of the table user and reading more about Yii2-user, I have not found a clear mechanism to recognize 2 different users as a frontend and backend one.
Only the admin can CRUD users, but that one too can only be mentioned in config by their username. Meaning they are recorded as other users.
Did anyone really use Yii2-user on advanced template with the frontend and backend residing on the same server?
I am trying to understand what is the intended use case for app auth and app users. Im basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I hope this makes sense. Any assistance would be appreciated.
Thanks.
App Auth and App Users -- which is officially called Box Platform -- is essentially a white-labeled version of Box. I think of it this way: "Box" as we know it is software-as-a-service. It offers a web app, mobile apps, and all the trimmings. Box Platform is the platform layer upon which the SaaS is built, providing API-based management of users/content/comments/collaborations/etc. With Box Platform you have a walled garden in which you can build apps that leverage all the features of the APIs, but are not otherwise "Box apps."
I'm basically thinking about building an app that would use Box to store data of users that would subscribe to our service. Our service would allow each user to access and view their data.
This is an appropriate use case. With Box Platform you will be the owner and administrator of a Box enterprise and all the accounts and data contained within.
If I have an account that basically owns the data of all the subscribed users, can I use the enterprise access token as a base for authentication while using the user account token to restrict the user to only viewing the data from their specific sub directory. Or do I have to have a unique account with its own api key for every user?
I think it's generally cleanest to create unique accounts for each user as opposed to giving users a special subdirectory in the admin account. From there you can use the App Auth workflow to get an access token specific to that user.
I have an iPhone application that needs to collect data from an online MySQL database. I've written a PHP web service so I collect the data with JSON. The problem is that everyone can see the data if they go to the URL now. How do i secure the data transfer properly?
Thanks for your suggestions.
Typically, if you are showing data private to a particular user, then each user will generally have an account (user id and password). The app will pass the user's credentials to the server before the server will provide the user's data.
You can also do something similar using SSO integration, or OAuth (ala Facebook).
In some cases, your app may only pass the username/password on the initial call and receive a session ID, which the app passes on remaining calls. This allows the server to store session data.
Even if the data isn't private to a particular user, you can use accounts to restrict access and privileges for a publicly reachable web API.
In all of the above cases encryption such as SSL (HTTPS) must be used to protect the authentication mechanisms and data transfer.
I'm assuming your data is public for all users of your app, in other words, you don't want to implement a login mechanism for your users. If you just want to make sure you return the data only to users of your app and not to anyone who happens to enter the right URL in their browser, you will need to sign your requests, so that only requests from your app are accepted by your server.
I use a secret key that my app uses to create a hash/digest of the request which the server verifies (it knows the secret key as well). Also I make sure requests cannot be replayed if they are intercepted by adding a timestamp and a nonce. The timestamp is checked to be within 10 minutes of the server's timestamp (relaxed sync) and the nonce must be unique (server keeps the last 10 minutes of nonces). This way no-one can copy the same request, the server will just serve an error if they try.
This post explains how to sign your requests in a bit more detail:
http://www.naildrivin5.com/blog/2008/04/21/rest-security-signing-requests-with-secret-key-but-does-it-work.html