Ok, the beginning was terrible, I just made installation by myself. Dont assume that people have same editor with auto class insertion and if you show all the code straight from the docs, we assume that you show all the lines that need to be run, but turns out that you skip some of them, so we still had to go to the docs. If we end up using docs as you did, then why we need the video part? :) In addition to that what is "pa" command? Its not found in my env. I dropped the video straight after this last drop :/ Tip for the next time either ask people to have installed specific libraries by themselves and begin straight away with other stuff, or show ALL the lines.
I get error >> TypeScript error in /var/www/react/react-spa-laravel-typescript/client/src/pages/homepage/index.tsx(10,10): Type '{ children: Element; }' has no properties in common with type 'IntrinsicAttributes & Pick'. TS2559 8 | return ( 9 | > 10 | | ^ 11 | 12 | 13 |
Thanks for the video, I had a query: now as we built the endpoint to get access tokens, the problem is the users can use tools like postman to make api calls directly without using our frontend. Suppose we are building an eCommerce and on flash-sales users are directly using our APIs to place an order, instead of going through the whole checkout flow.
Well, even if APIs are used there are checks and balances which will stop the user from exploiting. First, while registering I am assuming you will have an email validation policy. So, even if user registration is done through API, the verification cannot be automated. Yes, after login in to the system, the user can automate a few steps. But, the payment verification will happen through webhook. And there is API rate limiting in place to ensure no user is misusing the APIs. And if you are running an Ecom site, ideally you will have some basic firewall in place which will save you from ddos attacks. And automation can be done to non-api sites as well. For example, people have used laravel's dusk to automate form filling and stuff. There, you interact with actual page where card token is generated because dusk opens up chrome browser.
@@amitavroydev Thank you so much for the detailed response. I think now I understand what to do, atleast I'll allow CORS using config/cors.php only for my frontend domain, so that modern browsers will block those request if user on other domain. And also I can have some kind of human verification OTP/Captcha etc.. on few endpoints.
@@aniket-in Hi Aniket glad to be of help. Yes, CORS will help to a certain level if API calls are made from Javascript. However, note that if the calls are made using POSTMAN or something like Guzzle for PHP, then CORS won't be able to help you :) So you see, security is a big thing in itself and there are no clear simple solutions to any security concern. There are always some precautions that we can take. Yes, on important API endpoints, captcha is good specially on form submits because they most probably will result in some inserts. And, you don't want your database to suddenly start inserting 1000s of requests. If you have any more questions, feel free to get in touch. Cheers.
Another option will be to use a user api which is default and validate the current api token vs existing api. If it's not validated you can create a new or log out the user. This way we used in mobile apps.
Laravel will validate the token when an API call is made. So, to do a separate call is unnecessary and also not very optimal. The idea is that the user might be able to see the ui of a page if a token has expired because the JavaScript part of the application will load assuming that the token is present (and it won't validate the authenticity of the toke). But the moment you hit any API to get any kind of data from the server, because the Authorization token will be validated, it is going to validate, detect and accordingly the front end can logout the user But yes, this is with the assumption that looking at ui doesn't have any logical impact. But, if the requirement is that ui should not be visible, then validate the token on page load and keep that as a state variable or context variable.
Well Nazim, there is not much change in the authentication mechanism even of you have roles and permissions. The basic thing is, when the user logs in, you will need the API to send the role and permissions information along with the token so that if there are certain menus links or components that are role based, can be handled. The main thing is, having the API set up with that information. And typically I would use spatie permission to do that in the API. Last but not the least, whenever you have role and permissions in front end and backend, always validate the action's permission for the current user at the server and don't rely on the client. The client can take information to do certain things at the front end. However, for any action double check at the backend
Got it... Nextjs has quite a few things to help in this. Might want to check this if you have not done this already nextjs.org/docs/advanced-features/security-headers
Yes, the Laravel version is 7.*. However, so far I have not done anything which is specific to Laravel 7. Everything will run even on Laravel 6 or even on 5 I think.
Yes, the idea was to start with the code base as starting point. I have done a lot of component structuring and all which I felt doesn't warrant a tutorial.
