First Time User Setup - php

I'm building a system with users and roles using Jetstream(Livewire)/Fortify auth, but it's a closed system (I mean, there is no way to register yourself, you must be invited) so I disabled Fortify's registration feature, but I want the first user to be able to register himself.
In other words: Fortify's registration should be off, but while there isn't an user in database, it should be on (email validation too, but If I can figure out the registration part, the verification should be easy).
I tried making an middleware to check if there isn't a registered user and redirect to register view, but I found some errors (like the view doesn't even exist 'cause fortify registration is off).
Does someone know a way to make this work using the Jetstream stack? Thanks!

and what about this, in the FortifyServiceProvider.php boot method
Fortify::registerView(function () {
if(!User::all()->count())
return view('auth.register');
else
abort(404,'No registration allowed');
});

Related

How to generate unique register URL in Laravel 8.*

In my application I need register and login function. But functionality of my app requires that only some people will be able to have accounts, while I still might need to add new users.
I was thinking about 2 options.
Disable register routes and generate unique, 1 time register url which I would send to my future user.
Add column in users table and somehow only validated(by admin) users would be able to use app.
Since second option as consequence would require me to rebuild whole app Im wondering
Is it possible to create unique register urls?
I havent done anything yet towards solution, I dont know where to start really so I cant provide any piece of code or error
Consider using signed URL's in Laravel:
$url = URL::signedRoute(
'register',
now()->addMinutes(30)
);
Then we can modify our registration route to determine if that signed URL is valid:
public function register($request) {
abort_unless($request->hasValidSignature(), 403, 'That link has expired or is no longer valid!');
//they can register now
}

Laravel 5.0 multiauth

I have an application which has two parts back-end, and front-end. In the back-end admin can log in, and in the front-end the client can log in. Now it has been implemented. All application's query is done by logged in user id in both admin and client end.
Now my app needs a functionality where admin can view client data as same as client see their profile.There are a lot of things in client end. I can you use Auth::loginUsingId($client_id). Here client profile is showing perfectly but admin loggin session is lost as expected.
How to achieve this while admin login remain and admin can see client full data?
Let me introduce the simpliest way to have login as client functionality. First, define asuser and returnback routes.
Routes and actions
Route::get('/asuser/{user}', 'AdminController#asuser')
->where('user', '[0-9]+')
->name('asuser');
Route::get('/returnback', 'ClientController#returnback')
->name('returnback');
In admin's controller:
public function asuser(User $client, Request $request) {
/* insert checking if user has right either here with some field
* like $user->is_admin or using middleware settings and Policy
*/
# who user is
$fromId = Auth::user()->getId();
# logging as a client
Auth::login($client, true);
# but keeping admin in a session
$request->session()->put('adm_id', $fromId);
return redirect()->route('some-client-route')
->with('status', 'You are logged in as a client');
}
And for returning back ClientController
public function returnback(Request $request) {
$fromId = Auth::user()->getId();
# getting admin id
$admId = $request->session()->pull('adm_id');
$adminUser = User::find($admId);
if (!$adminUser) {
return redirect()->back()
->with('status', 'Not allowed');
}
# logging out as a client and logging in as admin
Auth::logout();
Auth::login($adminUser, true);
return redirect()->route('some-admin-route')
->with('status', 'Welcome back!');
}
Is it ready for production
No, it's not. That's not a great solution, it's just a glimpse how to use it. Sessions have lifetime, so if admin doesn't return back in its lifetime, session variables are lost and he becomes a client (if remember me=true, as in the code above). You can store value not in a session but in a database column.
In addition as t1gor mentioned, you must pay attention to the fact that you can't log client's actions and send events when admin is a client. That's the most serious problem of logging as a client. Anyway, I suppose, it is easier to solve that, than to move all the auth logic out of the views.
Well, hope it is helpful.
I think a good way to manage client/user profiles is to implement an user management section at your backend, display and edit your users and their profiles there.
Laravel does not provide mixed sessions. You can only be authenticated as one user at a time. If you really need this kind functionality in Laravel 5.0 you could solve this by hackish user ping-pong (e.g. login temporarily as client and switching back to admin right after).
But it seems like your problem is more Authorization-related (in contrast to Authentication). Laravel implemented an authorization layer in v5.1.11. Since v5.0 is not supported anymore you should update regardless of this feature.
You can find more information about authorization in the official documentation: https://laravel.com/docs/5.1/authorization
I would rather suggest you separate the view logic e.g. business logic into some common layer rather then doing a "login-as-client" functionality. Even though it looks like a short-cut, you'll have a whole lot of things to think about.
For instance, how do you log application events now? Add a check everwhere that the session has a adm_id and log it instead of userId? This is just one example.
What I would have done:
Separate the view (e.g. user profiles, user content, etc.) from the session so that it is accessed by the ID in the URL or whatever else method, not by currently logged in user id.
Implement a propper role-based ACL. There are plenty of packages already. In your example, you wouold have an admin role and a client role, both havin permission object view-client-profile, for instance.
In the end, this might take a lot more time for development, but would defenitely save you some time debugging/troubleshooting with the angry client on the phone. Hope that helps.
I think middleware is the best possible option to filter the content between the admin and the normal user,because the code in the middleware run before any function call.
You just only need to set the usertype in the session and filter accordingly.
Visit:https://laravel.com/docs/5.4/middleware

Login/Register without Laravel's Authentication Services

I am new to Laravel and felt that the Authorization system provided out of the box is difficult to customize and implement.
Is it a good idea to implement the Login/Register functionality from scratch using controllers and middlewares in laravel?
For example, a middleware 'webAuth' will keep a check on whether the user is logged in just by checking request->session()->has('userId').
The login controller will take email and password and search for user the user in database using email, get the password and Hash::check() it with the one provided by user during login. If the password check succeeds, the user will get be authenticated by setting $request->session()->put('userId', $user->userId).
Finally, a register controller can create a new user by taking in the details such as name, email, password, dob etc. using a form and creating a new user model. The user can then be logged in using the same method as mentioned above.
The login and register controllers will of course use Validator and may also redirect user appropriately.

Laravel User Registration

I'm looking for a way for users that are logged in to register new users. I don't want unregistered users creating new users. The problem that I'm coming up against is that Laravel does a lot of rerouting when you use their registration controllers so that it auto reroutes you away from the registration page if you are already logged in. Is there a way that I can get around this functionality without having to rewrite all of the registration logic?
I've tried simply adding auth middleware to the registration route but it immediately reroutes to the home page of the app before you hit the registration view. If I create a route that redirects to the registration view like this-
Route::get('register', function(){
return view('auth.register');
});
It will give me the registration page but silently fail to add any users to the database. I think it may be because the RegistersUsers class has use RedirectsUsers as its first statement. Short of rewriting the code there is there another way to accomplish what I'm trying to do?
I'm using Laravel 5.2 with the make:auth standard views

Restricting 'Users' in Laravel while still allowing everyone to edit their own 'User'

I'm still learning Laravel & best practices.
I have a user system, so that you can create & update users through the UserController. Only admins should be able to access users & manipulate them. So I've created the following route:
Route::resource('user', 'UserController')->before('role:admin');
All looks good and works fine. I've got a filter that checks that the logged in user is an admin before they can access anything to do with users.
Here's where I'm getting confused. A user who logs in and is not an admin should still be able to edit their own information (email, password, username). I've setup a new form using the same form partial I have setup for editing users as all the fields are the same, and I thought i'd be able to process the form using the same form method so as not to duplicate the processing, which is identical:
{{Form::model($user, ['method'=>'PATCH', 'route'=>['user.update', $user->id]])}}
Except, because my user isn't an admin, they're getting pushed back to a 403 message instead of it processing the script.
How do I make an exception for a user to edit their own info, without loosing the admin restrictions on the UsersController?
Easy solution is to create an AccountController with different access restrictions. Any common processing done between UsersController and AccountController can be moved to the model.

Categories