Have the below route defined in web.php Testing Using laravel 5.5 in my local mac laptop withvalet
Route::get('/cart/add', function () {
// Only authenticated users may enter...
return "hello owlrd123";
})->middleware('auth.basic');
First time when I hit the url http://eshop.dev/cart/add it prompts for username and password. When i enter the valid credentials it displays the message "hello owlrd123". Cleared the cookie & session(laravel_session,XSRF-TOKEN) in chrome and when i hit the url again it doesnt prompt for credential it directly displays the message "hello owlrd123". How does it remembers the session? I dont want it to remember the session.
You are using auth.basic, there is no proper way of logging out with Basic Authentication, it was simply not designed to handle logging out.
There are some ways in which you could invalidate basic auth, but none are proper fixes.
Closing browser completely
Pop up another auth window and send a 401
See these answers for more info:
- How to log out user from web site using BASIC authentication?
- How to logout user for basic HTTP authentication
Main question is:
Why are you using basic auth instead of cookies for this?
Related
How can I authenticate a user with sanctum when the whole login process happens server side? The question I am asking is kind of hard to phrase so I will explain my situation.
I have a Vue SPA for my front end and a Laravel app as a backend api (they run on the same domain). Normally, to authenticate with the laravel api using sanctum, you would send the credentials in a post request, and if the login was successful, you would get the session information returned. However, I want to use steam login for authentication. I already have to whole process on the backend figured out in terms of actually logging in, however I am unsure how to pass the session data back to the SPA. Currently I have a link on my site that takes the user to the login endpoint on the api, and that endpoint will have them authenticate with steam, so the entire login process is handled on the backend. Now I just need to figure out how to send the session data back to the SPA. I guess it world be similar to using sanctum with socialite.
So far I've tried usisng Sanctums Mobile Aplication Authentication. I did this by having the user log in into the laravel app using steam, then once authenticated, a access token for their account would be created, and they would get redirected back to the Vue apps call back file, with the token as a part of the query string. Then the token would be stored and . This worked, however it presented some security issues.
The token was passed back in the url, so anyone could screenshot it and use it
Anyone who obtained the token by some other method could use it.
Here is the code for what I tried: https://gist.github.com/DriedSponge/4e8549486c2bfa33e4c0b21a539bdf85
So in summary, I want the entire login process to take place on the server, but somehow at the same time authenticate the SPA. If you have any ideas on how I can make this work, please let me know. If you have any questions just leave a comment. Thanks in advance.
I try to run Koel (or Kutr, a fork) behind a HTTP basic auth user/password dialog: https://koel:8001 behind an nginx reverse proxy https://koel with basic auth enabled.
Koel is a Laravel application and uses JWT tokens and the Authorization Header field like this:
Authorization: Bearer eyJ0eX…
This means that every request overwrites the basic auth header (that uses the same field) and the login dialog pops up again and again.
When I set APP_URL in the file .env to https://user:pass#koel, all links to static files are indeed properly fetched. API calls like https://koel/api/data unfortunately ignore this.
Can I use some kind of Middleware to inject user and password into the API calls?
The principle of JWT is to avoid using basic auth which is like no authentication at all (your credential are transmitted in clear with basic authentication).
So, I'd say that JWT using Authorization is a good thing, since it prevents your credential from leaking in case of bad configuration.
The principle of JWT is to, upon valid credential, to generate a token that's stored in your browser (a bit like a cookie). Then, with this token, there is no need to present any authentication whatsoever (so the credentials are present only once upon authentication, no during the complete session like for a basic or digest authentication).
With Koel, you can't do much to prevent this, since there is no way to change the login page in order to use basic authentication.
With Kutr however, I've done some hooking mechanism so you can plug your own login page (which can be as simple as validating a basic authentication).
It's available here
In your case, replace the top of the file from:
// Require your CMS bootstrap code here
require_once("yourCMSbootstrap.php");
// Bootstrap your CMS and check the session is valid (if not your CMS will fallback the login screen)
checkSession();
to
// Assert the user provided an basic or digest authentication
if (!isset($_SERVER['PHP_AUTH_USER'])) {
header('WWW-Authenticate: Basic realm="My Realm"');
header('HTTP/1.0 401 Unauthorized');
echo 'Text to send if user hits Cancel button';
exit();
} else {
$login = $_SERVER['PHP_AUTH_USER'];
$pw = $_SERVER['PHP_AUTH_PW'];
if (!checkValidLoginAndPW($login, $pw))
{
header('HTTP/1.0 401 Unauthorized');
echo 'Game over';
exit();
}
}
Make sure the user's login also exists in Kutr's application
It's so strange that this simple solution is not yet implemented or is it that I can't Google it ;p) (I'm trying from last 5 days).
My requirements:
Call from Angular App (withCredentials = true) on a URL to see if it is windows user (challenge NTLM). (I may configure this based on what URL user accessing it). If it's a valid Windows user and I find them in DB, I return the Bearer Token.
If Above call returns Unauthorised (401), I show login form to user in my AngularJS (1.6) client. User provides non-windows username and password and when user click Login, from angular service go to another URL (for getting Bearer Token - standard OWIN stuff).
** In any case above, I store Bearer Token in my client for any further API interaction.
I'm not using ASP.NET identity but I have my own DAL to verify user from DB.
I'm going to have my own custom Authorise (inherited) attribute (which will check for Bearer Token only).
I don't want users to enter Windows login on my form and to authenticate them from Active Directory.
I Don't want windows users to click on any separate button to login. (They should just login seamless - with prompt from browser asking them windows login)
I've seen hundreds of posts but nowhere I could see exactly what need. Either the mixed authentication needs to be Cookie based or separate MVC implementation. (Lot's of confusion)
Already referred:
https://techblog.dorogin.com/mixed-windows-forms-authentication-for-ajax-single-page-application-e4aaaac0424a
https://techblog.dorogin.com/mixed-windows-forms-authentication-for-ajax-single-page-application-e4aaaac0424a
https://github.com/MohammadYounes/OWIN-MixedAuth
Don't know if this may help: (but again with cookie) https://github.com/pysco68/Pysco68.Owin.Authentication.Ntlm
Can someone please help?
I may have to give up on this by tomorrow evening :-(
I am using Ionic to build a login system on top of Codeigniter/Ion_Auth/codeigniter-restclient and when I try to login from "ionic server" the login works but the next api request to the logged_in() method returns false.
The same thing works properly when I point the browser to the www folder.
So here is the problem step by step:
run ionic serve
you see the login form (http://localhost:8100/#/app/login)
enter email and pass
the rest api returns "login successful"
$state.go('app.profile') works and redirects to http://localhost:8100/#/app/profile
REST get api/logged_in returns false and I redirect to the login page
If I do the same in a regular browser, step 1 becomes: open browser and go to http://localhost:8888/App/www/#/app/login, at step 6 REST get api/logged_in returns true and I don't get redirected to the login page, I stay on the profile page.
The code is the same. So my guess is that maybe ion_auth doesn't get the cookies it wants or the session is reseted. I am not sure at this point what the problem is. This is my first Ionic/App project so I might be missing something about the proper way to authenticate from a mobile app using code that works in browsers
Thank you
UPDATE:
It seems that when using the 'ionic server' window every request to the API triggers a new session. The new session is stored in the database and ion_auth tests the logged_in against that last one, which doesn't contain the login details.
you were taking about REST api and cookies and sessions. Cookies and sessions don't go with REST philosophy. Here is why.
Let me tell you how we accomplish this problem in our project. Basic way of knowing which user is requesting and if it has the access rights is by the 'Authorization' header value. You can use Basic Authentication, Barer or any other.
We generally prefer token based authorisation system. When a login is successful, server sends a token. In ionic app, we save it using a factory called SessionService. So whenever user logs in, token is stored and is used for every request. But token would be lost if user closes the app. So we can store it in local storage. User can then be directly redirected to dashboard until user logs out.
app.factory("SessionService", function($window){
var user={};
if ($window.localStorage['user']!=undefined){
user=JSON.parse($window.localStorage['user']);
console.log(user);
}
return{
isLoggedIn:function(){
return !isEmpty(user);
},
logout:function(){
console.log("logout")
user={};
$window.localStorage.clear();
},
setUser:function(data){
user=data;
$window.localStorage['user']= JSON.stringify(user);
},
getUser:function(){
return user;
}
}
})
Now in every web request, you can call SessionService.getUser().token when setting value Authorization header.
UPDATE:
Despite using cookies is not recommended, you can use it in your application easily.
If you are sending request with CORS, angular doesn't sends cookies with request.
One of the way address this issue is to send withCredentials: true with every request:
$http({withCredentials: true, ...}).get(...)
Read further about this here.
Hope this helps!
I have a website that I would like to allow both Forms and Windows Auth for. My problem is that it seems that when you setup IIS to allow both anonymous (Required for forms auth) and Windows auth that the browser won't send the user's network credentials.
It just uses the anonymous login. Is there any way either in IE8 or IIS to have it try Windows Auth 1st and then fall back to Anonymous?
Thanks for any help.
You can't ask for HTTP authentication (whether that's Basic Authentication or Integrated Windows Authentication) without causing the authentication dialogue box to pop in the case where there are no credentials yet.
So in general for hybrid HTTP-auth+cookie-auth approaches you enable both anonymous and authenticated access for the bulk of the site, but allow only authenticated access to one particular script.
When the user accesses a page without either kind of auth, you spit out a page with a login form for the cookie-based auth, and also a link to the one URL that allows only authenticated access. The user can fill out the form for cookies&forms auth, or hit the link to log in with HTTP auth instead.
If the user follows that link, they will be given a 401 response and must provide HTTP authentication, either through the auth dialog, or potentially automatically using integrated Windows authentication. Once this has happened once, the browser will start submitting the same credentials to every future page, so IIS will decode the credentials to give you the expected REMOTE_USER when your main site scripts are run.
Browsers will only submit the credentials to pages in the same directory as the 401 script, or subdirectories of this. For this reason it is best to put the HTTP-auth-required script in the root, for example as /login.aspx.
However, there are a few browsers that won't automatically submit credentials for further pages, and require every HTTP request to respond 401 first, before sending the request again with credentials. This makes optional-auth and hybrid-auth schemes impossible (as well as making browsing of protected sites much slower!). The only modern browser that does this is Safari. You may not care, as Safari's support for Integrated Windows Authentication has traditionally been shaky anyway, and it can still use the forms+cookies auth type.