I'm wondering how I can password protect pages (therefore web routes) without any auth. My website doesn't have user login/register system, it's not needed.
All I want is to have a several password protected pages that each have a unique password, these passwords are stored in a database.
How would I go about doing this?
Two steps.
create a page for requesting password, also include which page he is trying to access, if user enters the password correctly, set session variable saying pageX is authenticated and redirect to the page.
Create Middleware that checks for the session variable, if it doesn't exist redirect to password page.
I prefer to combine it with javascript window.prompt and session laravel.
Create a pop up to insert the password of the page.
https://www.w3schools.com/js/js_popup.asp
redirect the result to a route, in the controller search the password form database.
use session from laravel, so if the password exist set the session.
https://laravel.com/docs/5.0/session
4.the session isset is null, redirect it to another route.
Related
I'm trying to make a user logged in at back-end who is already a user of another website of mine. For now I'm able to fetch the user's data from previous website's database using an API and make user registration during the login process. Same time I want this user to be logged in when data is just inserted because now user is existing. I tried to reuse same method $this->processLogin(); but this method takes request function processLogin(Request $request) I can't feel passing email & pass to utilize this same method. I have tried guzzle self request with 3 parms 'email, password, _token' using POST request which didn't work. I don't want to exclude this route as well because it is being used for normal login. How can i make this user logged in right after inserting the required data? Please advise. Thanks in advance.
// if $id is your user that you want to login, then:
auth()->loginUsingId($id);
I am new to Laravel. I am using Laravel's auth controllers for login/register on my website. After login/register, it will redirect to a dashboard. This is fine.
The problem is when the user (not logged in) submits a particular form. The form submission will take the user to a protected page. The auth system will intercept this (if not logged in) and ask for the user to login and the user can sign in. But after the sign in it won't get redirected to the actual destination. Instead, it goes back to the previous page. I tried the redirectto->intended() way in the middleware. It still does not work.
Found the solution. Use HTTP session. I am not sure if this is the best method.
POST the form to a route which doesn't need authentication
Validate and store the form data in the session using the controller
Redirect to the protected route where the auth will intercept and ask the user to login
After successful login, redirect to the original destination page using return redirect()->intended('defaultPage');
Access the form data from session inside the blade view
I am not storing any sensitive data in session. I have no idea how secure this method is.
If you have any suggestions please post.
I'm looking into an "authenticated URL" type middleware for my Laravel application where a token is generated and that token relates to an authenticated user ID and the hash of a single URL. In other words, a way of viewing a session page from an e-mail without being initially signed-in, using a high-entropy token.
When the user visits the URL, for example https://www.example.com/some/url?authtoken=WDu4UQ5SQr4WGlfMYErxRy3hjdFMs02f2NqbQ7PA, the AuthenticatedUrl middleware looks up the authtoken in the database, verifies the hash of the request's URL and the stored URL match, then logs in the appropriate user ID (Auth::guard('user')->login($token->getUser())) so the page's controller can respond as normal.
That being said, I would prefer to only allow this middleware to authenticate the request itself, not the entire session. Is this possible without causing issues with an existing normal Laravel session?
I discovered the Guard::onceUsingId($id) function which does exactly this. It logs in the request without setting any related session values or cookies.
I have a spring controller method which could be called in different scenarios. here is the example...
#RequestMapping("/resetpassword")
public ModelAndView resetpassword( #Valid #ModelAttribute("resetpasswordForm") ResetPawdFormForm resetPawdFormForm, ModelAndView modelAndView){
... this method could be executed in 3 different scenarios....
using the hyper link coming from the user reset password link sent to user email..
eg: localhost/myApp/login/resetpassword//
Here I can authenticate userID and activationSecretCode in DB and let user reset password
user can click on resetpassword link from user settings page.
eg: Since the user is already coming from user settings page, I can validate userSession and allow him to reset password
User can login for first time successfully, but are forced to reset password due to admin requirements for reset initial default password.
eg: in this user neither have session, nor passing any activationcode to validate.
login method validates userid/default password and redirects to resetpassword mapping(method=GET).
How can the system authenticate the user request and allow him to reset password?
One alternative for this is, to use flash attributes and set a authenticationKey as flash attributes...which could be verified in resetpassword method.
is there other way to implement this....
Note: I posted an issue in implementing this approach in
Post: Spring: How to pass Java objects during redirect while using ModelAttribute
Any help?
I think the best way to implement this is using three different action methods:
resetPassword (e-mails)
resetLoggedUserPassword (via settings)
changeDefaultPassword
They may even share the same view, but the behaviors are not equal, so I would avoid overloading the action responsibility.
EDIT: elaborating on your comment:
1) To secure the e-mail link, one way is to add a authentication token. The token can be as weak as a hashed user id plus some salt string, or as strong as a GUID with expiration time in a database table, generated whenever a user requests a password reset.
2) The settings way is not a problem, considering that the user is already logged in.
3) The temporary password action can be secured the same way as 1, or the same way as 2, if you put the user on the session. Logging in the user even with the default password status shouldn't be a concern if the code that verify the status of the account are inside a request filter.
My Users can change their passwords on a form. If this the form is valid I encode it, invalidate the session by using
$this->get('security.context')->setToken(null);
$this->getSession()->invalidate();
...flush the user to the database and do a redirect (to the same url).
Beside this I have a mechanism to store some information in the session before forwarding and showing this data in the 'forwarded' template.
Both work well on their own, but not together :-)
I can see, that the value is written (after invalidating the session) and I believe, that symfony instantiates a new session.
I just don't know, what happens after that. Maybe symfony is doing 'some magic', because it 'injects' the login-page before show the redirected url.
I don't really understand what you're trying to do, and why you're invalidating the session, but your User need to be logged in to see the redirected URL.
Your code logs him out.
You can log a user by doing so :
use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
$authToken = new UsernamePasswordToken($user, null, 'secured_area', array('ROLE_USER'));
$this->get('security.context')->setToken($authToken);
The third parameter is the providerKey, and the fourth is a roles array.