Home > OS >  is client side authintication "like on SPAs" is just a lie to prevent users who choose to
is client side authintication "like on SPAs" is just a lie to prevent users who choose to

Time:09-19

a question that may be stuped sorry. is client side authintication "like on SPAs" is just a lie to prevent users who choose to belive it from trying to play with the data on the back end "wich protected with real authintication" ? becouse when we develop spa whith ['vue, vue-router', 'react, react-router'] we do a layer of authintcation that oprates on client and cleint side data (stores, and localstorege) and since we ship all the code to the end user is that make the authentication code is just a lie and easy to find a way to hack around it ? "yes the api is protected becouse the data on the api is there on the api" iam not saying that should we develop spa without authintciation and protected routes, but does it work with users how know some js and have the curisity to access our app UI "at least the ui" ?

CodePudding user response:

In a sense, yes. When there is client-side logic that checks a user's role or authentication access, that is for the sake of usability rather than security and should be present only in addition to the actual secure checks on the backend.

For example, a well-structured SPA might choose to redirect a non-admin user away from a /admin page they are not supposed to access. This does not have anything to do with the actual security, it's just to avoid confusion and a seemingly-broken app when the actually-secure API endpoints called by that page inevitably return 403s.

  • Related