I have been very much wondering how the attempt method works at background in Laravel, how it creates user session. My authentication process is much different, I am not using the database to authenticate at all, but instead I am using some data from third party API and then generate user sessions in my application.
During this implementation I do want to use the amazing laravel Auth features.
I know this is doable, may be there is a simple process for this, but I am not understanding the correct one.
Related
I start building a new app and wonder what will be the best way to implement auth - security wise.
What are the cons, pros, and differences between the Laravel make:auth and using jwt-auth.
Is Laravel's default auth will be enough?
This description is pragmatic approach so you can do something else if you want.
I think while developing an API you should use JWT based authentication mechanism.
The Json Web Token(JWT) tokens includes user information in itself. So it giving so much important benefit to manage session. First and most important of the benefits is you can be manage sessions without storing them at server. I would like to explaint it just to avoid misunderstanding, you can have store it at server but it's not necessary except a few scenario. These scenarios depend on how you could designed your authentication.
I able to do a lot of more explains about of it but in summary if you are developing an API I propose you would use JWT-Token.
My site has a unique setup where the user logins in via OAuth (Socialite) and during login we populate their session with data from this 3rd party. It's an essential component of our application. So using Dusk offers limited value unless I create a user on this 3rd party and actually login, unless I can mock/seed the session. I've been doing some googling and looking through Dusk itself and it's not immediately transparent if this is possible. Is mocking/seeding the user's session data possible?
Take a look at how Dusk handles logins by registering special routes in DuskServiceProvider and calling them in InteractsWithAuthentication.
I image you can use a solution like that for your situation.
I am developing a web system in php using the laravel framework, I arrived at the part of authentication of users, where it is not allowed the type of user x access to page y. What is the best way to do this with laravel? I thought about creating a session and saving the id of the user, so every time he accesses a certain controller I check if he has access to the id or not. so I had some doubts.
Is this a good way to perform this authentication?
Is this really safe?
is there any way for the client to change my session?
What would be a better method for authenticating user access?
Laravel provides a very good authentication system out of the box. Even though Hacking is inevitable it provides very good protection and since Laravel is pretty popular framework you don't have to worry about the security part. if there is any security bug, patches will be available almost immediately.
And your second concern can a client can change the session ? the answer is NO, if you code it properly. session resides in the server unlike cookies, so there is no direct way for a user to change the session. if you follow good coding practices you are good to go.
And how do you limit userA from accessing pageB. This is a pretty common feature needed in almost all the applications. As of now Laravel does not provide an out of the box solution for this. but this is pretty simple, you can add a role column to the users table, and check whether user have appropriate permission in each page. Laravel keeps the user object in the session, and it is avilable via the auth() helper or Auth Facade. if you want a little sophisticated solution there is a package out there [entrust][1]. it seems a good choice.
You may want to read about
Authorization
Csrf Protection
Authentication
I hope I have addressed all your concerns
Laravel provides a simple way to authorize action thats purpose built for what you need:
https://laravel.com/docs/5.5/authorization
I'm trying to build an internal admin system to get to grips with creating a Laravel app from scratch. Currently everything is public so I'm looking at implementing a very simple login system.
There will be no DB connection needed as we want a single user. We'll store the relevant username and password in the .env file most likely.
I feel like I've looked everywhere and haven't been able to find any tutorials covering this requirement! From everything I've read it seems I have to use a 'custom authentication driver' or possibly build my own user provider class but I have no idea how to go about this task.
The idea is that if the app is expanded in future we'd like to be able to just go back to using Laravel's built in db auth functionality. For this reason it would be nice to retain all the common methods relating to checking the current user, using auth middleware on my routes and managing login tokens etc.
Thanks in advance for any help offered.
I implemented codeigniter Ion_Auth library for user registration and etc. I noticed it does not have a built-in user manager such as edit user accounts. Does a user manager such as edit user accounts exist? I can always code one, but I rather not reinvent the wheel.
I use Ion Auth too, it is pretty well coded I and I like writing code with it.
I also needed users editing, but I find it quite easy, because I needed only one simple form, because the library has update_user() and you need only to pass an array with your new data.
Download a CMS because it looks to me you have little or no experience with codeigniter or php for that matter. I dont mean that in a rude way by any means but if you cant perform simple CRUD operations, install a pre-built system as it will save you lots of headaches.
I've just started using CI and am also using Ion Auth for authentication. I'm handling user signup/authentication exclusively with ion auth and extending public profiles using Grocery CRUD. All public info can be viewed globally, but only edited by the user that owns it (as defined by linking the ion auth user table to the extended profile table). I don't know if this is the best way to do it, but it is what I'm doing so far.