Using Laravel 5.5, and Laravel's built-in authentication system.
Confused about the Remember me option, this is my remember view
<div class="col-xs-6">
<div class="checkbox checkbox-primary" style="margin: 0;">
<input id="checkbox-remember" type="checkbox" name="remember" {{ old('remember') ? 'checked' : '' }}>
<label for="checkbox-remember">Remember me</label>
</div>
</div>
When checked, it does add the remember_token token in the User database, so that part works. But it doesn't seem to 'remember' anything? All users whether they have a remember_me token or not can access the website straight away if they close the website/open it again. All users need to re-enter their email/password if they sign out and the remember-me box is not checked whether they have the remember_me token or not.
Tried both the file and the cookie session driver.
Struggling to see what exactly does it remember?
The remember me functionality from Laravel provides an automatic login for users who signed in with the remember me checkbox checked. This way users who closed their browser or killed their session don't have to login again.
Contrary to other websites (or some browsers, for that matter) who remember the credentials and put them in the login for you, Laravel doesn't do that.
As Laravel states in it's documentation:
If you would like to provide "remember me" functionality in your application, you may pass a boolean value as the second argument to the attempt method, which will keep the user authenticated indefinitely, or until they manually logout.
Related
I am trying to request an access token from Google do I can access a Google Drive account, to upload files.
I can make a an Auth request ...
<form method="POST" action="https://accounts.google.com/o/oauth2/auth">
<input type="hidden" name="scope" value="[YOUR SCOPE]"/>
<input type="hidden" name="client_id" value="[YOUR CLIENT ID]"/>
<input type="hidden" name="response_type" value="code"/>
<input type="hidden" name="redirect_uri" value="[YOUR RETURN URL]"/>
<input type="hidden" name="access_type" value="offline"/>
<input type="submit"/>
</form>
Why do I need the redirect_uri if I am making an HTTP request to obtain the access token. Wouldn't the token be returned within the response body?
My app does not involve any user interaction so I am not sure why a redirect is even necessary. I don't wish to use an SDK or library, rather I would just like to use HTTP via Postman.
My app does not involve any user interaction
Oauth2 does require user interaction to authenticate to a users account then your going to have to request access from them. A consent screen is displayed and the code is returned to the redirect uri
back to the basics of form submit ( without javascript), the form data will be sent to the uri you set in the action and the page will be redirected to what the server set it to, or page gets "reloaded" with a page that shows the response od the server.
I never tried Google OAuth2, but in general for this case, usually if your form submit is successful, it will redirect to your redirect_uri with the token appended on the uri as hash.
just realized u are using code grant type. so the flow is after this form submit, it will get redirected to Google IDM to authenticate and accpt consent, then redirect to redirect_uri with the auth code appended. then u can get the token by requesting it from the token endpoint with the code you obtained.
I have developed a Spring server that serves an Android app where
users can sign up via email or via Google. Sign up in this case is performed via grant type password / google.
Now, I am planning to let my server act as a OAuth2 provider where users can connect external clients and hand access tokens to them via authorization_code grant type allowing these clients to access certain REST API endpoints on my server.
The basic flow is like this:
On the external client, the user initiates a call to /oauth/authorize endpoint with parameters
response_type : code
client_id : id_of_client
redirect_uri : uri_where_external_client_can_receive_auth_code
custom design login page is shown, user enters username and password
after successful login, user is presented with the "confirm access" page (/oauth/confirm_access) and grants access to the client
after confirmation, the redirect uri is called with a code parameter usable for getting tokens
external client calls the /oauth/token end point with parameters
grant_type : authorization_code
code : auth_code_that_was_previously_returned
client_id : id_of_client
redirect_uri : ...
upon success, access & refresh token are returned
I have already implemented this flow, and it works.
Now I want to ramp things up a little bit and enhance my custom login page with the ability that users can not only authenticate via username and password to connect external clients, but also via Google.
The problem is that my login form currently looks like this (custom_login.jsp):
<html>
<head>
<title>Login</title>
</head>
<body>
<form action="/login" method="post">
<div class="form-group">
<label for="username">Username:</label> <input type="text"
class="form-control" id="username" name="username">
</div>
<div class="form-group">
<label for="password">Password:</label> <input type="password"
class="form-control" id="password" name="password">
</div>
<button type="submit" class="btn btn-success">Login</button>
<input type="hidden" name="${_csrf.parameterName}"
value="${_csrf.token}" />
</form>
</body>
</html>
As you can see, submitting the login form makes a POST request to the /login endpoint of my server which is out of my control and redirects to the /oauth/confirm_access endpoint.
If I want to support Google sign in I would have to add a Google sign in button to my custom_login.jsp and then I am pretty much stuck. I have no idea how I can validate the user that signed in with Google with my server like the /login endpoint does with username and password and then further redirect to /oauth/confirm_access endpoint. Does anyone know how to do that?
I've discovered a strange thing in my Laravel 5.1.28 web page. The session token changes in every request when I use a mobile device (android, iphone). I see this in two places.
One, on the development bar on the session tab.
Two, when I write in the view {{ csrf_token() }} (For example, I put <input type="hidden" name="_token" value="{{ csrf_token() }}"> in a login form and the _token changes in very reload.
This breaks my login form and I can't login from any mobile device (tested in moto 2 gen and on iphone 6). However, I've said, the token works well from desktop (firefox, chrome, ie) and from tablets (ipad).
Any clues about this? Thank you.
(Related to this, admin could think that this is the same question)
Solved.
The problem was a wrong value of 'domain' key in session.php. On mobile devices for any reason the cookies policies are more restricted.
I had got this value:
'domain' => env('SESSION_DOMAIN', 'www.[mydomain].com'),
I need to remove www., so this value must be like this:
'domain' => env('SESSION_DOMAIN', '[mydomain].com'),
For any reason from desktop browser with no special configuration the cookie works with no problem.
I have a simple form to create user registration, but when the form, submit it shows an error "token mismatch exception". I have already tried replacing the name field and id fields but I can't find what's wrong.
can any one please tell me what's wrong?
<form action="http://example.com/registration" method="POST">
...............
......
</form>
You have to add the CSRF token to your form:
<form action="http://example.com/registration" method="POST">
{{ csrf_field() }}
......
</form>
To quote the docs:
Laravel makes it easy to protect your application from cross-site request forgeries. Cross-site request forgeries are a type of malicious exploit whereby unauthorized commands are performed on behalf of the authenticated user.
Laravel automatically generates a CSRF "token" for each active user session managed by the application. This token is used to verify that the authenticated user is the one actually making the requests to the application. To generate a hidden input field _token containing the CSRF token, you may use the csrf_field helper function
it is becuase you are not passing the security token along with your form data.
please use
{{ Form::open(array('url' => 'foo/bar')) }}
........
........
{{ Form::close() }}
Laravel provides an easy method of protecting your application from cross-site request forgeries. First, a random token is placed in your user's session. If you use the Form::open method with POST, PUT or DELETE the CSRF token will be added to your forms as a hidden field automatically. Alternatively, if you wish to generate the HTML for the hidden CSRF field, you may use the token method:
echo Form::token();
you can find full documentation in this link http://laravel.com/docs/4.2/html
If I have this page in "http://example.com/login" with GET verb:
<form action="https://example.com/login" method="post">
<input type="text" name="login"/>
<input type="password" name="pass"/>
<input type="submit" value="Login"/>
</form>
Is it a security flaw? I mean, the page is HTTP but when sending the data it uses HTTPS. I have read several times that I should require HTTPS already in the login page, but I don't clearly see why.
Yes, it's flawed. What you have is secure as far as it goes, as long as it's your login form the user is seeing.
Because your login form isn't secured, I can come along and substitute my own spoof login form and collect your users' login details, eg. via a man-in-the-middle attack. A login system is only secure if both the login form and the target page use SSL.
Also, it doesn't look secure to the user. Users look for the padlock symbol on the login form, and yours doesn't have one.
Yes, it is a security flaw.
Since the form is served over HTTP, it is subject to being edited along the way. This edit could be, for example, the additional of JavaScript that sends the credentials to a server that the attacker controls as well as letting the browser log in normally.