I am working on an application that allows a social worker to conduct mental health assessments with their clients (usually children). This process normally happens face to face. A question is presented on a page, the social worker reads it to the client and the client indicates their answer (multiple choice from sad smiley to happy smiley), they click next and the next question is presented. I am trying to implement a feature to allow this process to happen remotely.
At the moment, only social workers have logins. The clients details are all in the db, so I would like to be able to email or sms a link with an authentication token that allows the client to have temporary access just to the questionaire page.
I am planning to use an API like pubnub or pusher to have the selected answers update on both the social workers view and the clients view as they change, so they can work through the questions together.
I am very new to Laravel and I am unsure how to go about creating a temporary session.
Looking at the documentation, there seems to be a number of ways to do authentication.
How should I approach this?
You can use signed URLs in Laravel. https://laravel.com/docs/7.x/urls#signed-urls
Signed URLs can be temporary, from the docs:
use Illuminate\Support\Facades\URL;
return URL::temporarySignedRoute(
'unsubscribe', now()->addMinutes(30), ['user' => 1]
);
later in your controller:
if (! $request->hasValidSignature()) {
abort(401);
}
Related
I Guys, i have to create a mobile app that need to make a request to a laravel endpoint, app no require registration or login, which is the best way to protect my api? To make sure the only my application can call it?
Thanks!
There's no full proof method of securing your api, because with the right tools and following some tutorials on the web, anyone could view your whole api request, headers, tokens, etc.
Anything you do or store on the app is already compromised, so signatures,ssl, encryption,tokens, etc are not that helpful if malicious users have access to the app. It can make it more troublesome for malicious users, but a dedicated one could overcome it.
Using authentication atleast forces users to register before they can use your api and you can block the user when needed. Along with requiring email verification, users who wish to misuse your api would then need valid email addresses atleast. But since you mention securing without authentication, this goes out of scope.
You can secure your api somewhat by using rate limiting. laravel has an inbuilt rate limiting with the throttle middleware. You can use this to restrict the number of times an api can be called in a particular time interval by an ip address.
Next would be Ip blocking. If any malicious activity is found, you could block the ip address. But this can be overcome with a vpn, and a malicious user could also block someone elses ip in this manner.
Captcha can help against bots, but would also annoy regular users.
Another method would be restriction with cors, those who have faced cors issues know exactly how annoying it can be, but it wont work on native apps (or you could try pwa).
And in a worse case scenario you could go with some terms and conditions and some legal action
A simple solution You can create a table for devices with api key which will be generated for each device app, and always use it to send requests to the api end point, then used it to fetch data from the rest api. The same process like if you are loging in, but you will use the api key unstead and the key will be fixe not refreshed evrey time.
I am new to laravel and creating a REST API. The client of the API will be mobile app only. There is no front end view to be shown in browser. I have created the routes and the controllers to handle API requests. Furthermore I deleted the Users table (created by laravel) because I do not need an Web interface etc.
I just want simple token based authentication at this stage ( I am aware there is passport authentication) but I can not even understand that at this stage.
There is only one table in the project.
Candidates
(id (PK), name, phone, details)
mobile app users are candidates also, should I create a token column in this table ? and manually create token at the time of register API and return it back as response ?
Please any simple guide or directions will help, I have search quite a bit online and there seems to be quite a lot many topics that show up such as guards, providers, passport which I am struggling to get.
Thanks,
Elliot.
First of all, you didn’t need to delete the users table. You can use it for api auth too. You just need to create a seperate token table.
However, if you want to implementit manually you need to do a lot of things manually.
This is a huge thing to impelement manually and it's not possible to describe it in a single answer. I will try my best to explain it as simply as I can.
You have to create a authentication system yourself that is for login. Define a middleware to check the authorization of the token sent from client to check the validity of every request (this is the guard part).
Also keep track of the token expiry time. Refreshing the token after each expiry needs to be done too (this is the provider part).
Now there are a lot things inside. Like keeping track of the device the request is coming from, providing different tokens for differenet devices for a single user etc.
If you are into learning how everything works then you can try to build one yourself. But if you plan on deploying it to a professional website, I would suggest try to get accustomed with passport. Reinventing the wheel is really not necessary. I hope it gives you a basic idea. If you have any more questions feel free to comment.
My question may be answered here, Are sessions needed for python-social-auth, but I feel as if I'd be making assumptions and would like to be positive regarding my understanding (NOTE: I'm not using django, I'm using mongo express react node, I'm guessing django might come with sessions built in or something). I followed this guide https://medium.com/hyphe/token-based-authentication-in-node-6e8731bfd7f2 to add token authentication and user login to my CRUD web app, works great, users are authenticated properly, routes are protected. However, everywhere I read about the fundamentals of session and session management states that "every web application in the world that maintains user data has to deal with sessions" (source: https://nodewebapps.com/2017/06/18/how-do-nodejs-sessions-work/). Currently, my react client uses setInterval to regularly check if the access token will expire soon enough to receive a new one via the refresh token. Is implementing sessions required for my app? If so, what is it that they add that I am missing?
It depends on the type of application.
If the resources being accessed using a token are not user specific, then sessions are not useful.
However, in a scenario where the resources are unique for different users (e.g. one has to sign in, etc), then it's wise to implement both sessions and access tokens.
Remember that tokens can also be saved within a session. Checkout 'express-session' to implement sessions in expressjs.
I've got a project made of two websites:
The front : A Laravel website without database and logic (just showing static pages and my javascript)
The API : A project using Lumen/Dingo API with my endpoints, my database, my logic and my models
I want to allow my front to ask data to my API depending the user.
Ex. I want to log the user, retrieve his friends, add some post to his
account, etc. (from the Javascript)
What is the best solution?
Using an identification per user (using o-auth or JWT)
Allow my front project to ask to my API then each javascript call needs to use my front without knowing my API) (In this solution I need to create routes similars to my API's routes)
Identification per user is always a better solution as the claims can be decided per user, also in future when it is required to provide permissions to access API based on claims or roles, it becomes easy to give information using the claims and amount of access you can give to a specific user.
So the way it will work is:
There will be identity server which will be containing the list of users in the system, and also the clams and scopes per user.
The API project will trust the identity server, that means any token provided by the identity server can get verified.
Based on the token per user your API app can decide how much information you want to give to the user.
That way in future you can have methods based on roles, claims and users will be provided with only the information that they have access to.
I am using the Plaid Link javascript library but I am running into an issue. I want to be able to use both the Auth and Connect products but the Link modal only allows me to show either Auth or Connect but not both. The documentation says to use Auth and then upgrade my token to use Connect. Which is fine I can do that. However the Auth modal will not show any credit only institutions like AmEx. Since I want both to allow for Stripe integration and for pulling in all of a user's transactional data across all institutions, what's the best way to do this?
Currently I am considering showing the different modals in two different flows (add a bank account vs add a transaction history account) but that is not very good UX. Also the IDs assigned by Plaid will be different and have different access tokens so deduping is a nightmare.
Or writing a custom modal that will use the Auth product for institutions with bank accounts (Chase) and the Connect product for credit only institutions (AmEx) but that will likely be a lot of work.
You'll only be able to use the Plaid Link + Stripe ACH integration for institutions that support Auth. I'd recommend initializing Link with Auth as the product and then upgrading to Connect once you have exchanged the Link public token for a Plaid API access token.
To answer the UX question you brought up - you can actually bypass using Link's standard "institution select" view and instead display your own list (you can use the /institutions API endpoints to pull information about supported institutions) using Link's custom integration.
That way, you can show your users a single list of supported institutions. If you initialize Link twice (once with Auth and once with Connect) you can jump directly to the Auth-initialized Link or Connect-initialized Link depending on the user's institution.