Laravel 9: Sanctum Login with Fetch API not working - laravel

Environment
Sanctum Version: v2.15.1
Fortify Version: v1.13.0
Laravel Version: v9.17.0
PHP Version: PHP 8.1.6
Database Driver & Version: Based on Laravel Sail (docker): image: 'mysql:8.0'
Description:
I am trying to get the login flow of my web app working. The web app is written using Nuxt 3 for the frontend (SPA) running on http://localhost:3000 and Laravel as the backend running on http://localhost.
Because Nuxt 3 is using the fetch API and axios is currently not available for Nuxt 3 I am trying to get the login flow with Laravel Sanctum and the fetch API to work.
Steps To Reproduce:
I am calling the Laravel Backend using a composable function on the frontend Nuxt App like this:
export const useLogin = async (email, password) => {
const config = useRuntimeConfig()
const tokenResponse = await $fetch(config.baseURL + '/sanctum/csrf-cookie', {
method: 'GET',
credentials: 'include'
})
const token = getCookie('XSRF-TOKEN')
console.log(token)
const loginResponse = await $fetch(config.baseURL + '/login', {
method: 'POST',
headers: {
'X-XSRF-TOKEN': token,
'Accept': 'application/json',
'Content-Type': 'application/json'
},
body: {
"username": email,
"password": password
}
})
}
Then I call it in a LoginForm-Component:
<template>
<form #submit.prevent="login()" class="bg-blue-500 flex flex-col rounded-xl p-4 text-white">
<h1 class="text-center mb-4">Login</h1>
<label for="fname">Email</label>
<input v-model="form.email" class="rounded-md h-8 mb-4 text-black" type="text" id="email" name="email"><br><br>
<label for="password">Password</label>
<input v-model="form.password" class="rounded-md h-8 mb-4 text-black" type="password" id="password" name="password"><br><br>
<button class="rounded-md bg-orange-700 cursor-pointer" type="submit">Login</button>
</form>
</template>
<script setup>
const form = {
email: '',
password: ''
}
function login() {
useLogin(form.email, form.password)
}
</script>
The problem is that I get 419 errors (csrf mismatch) back from the login route although the X-XSRF-Token is set in the request headers (like described in the Laravel Sanctum docs):
Is it possible that Laravel Sanctum handles the Header name case-sensitive and so it can't find the token? As far as I know the fetch API always sends header names in lowercase and there is no way to change this behaviour.
Additional information
The cookie is set correctly by the Laravel Backend:
The cookie data seems to be OK, too:
These are the Sanctum values inside my .env:
SANCTUM_STATEFUL_DOMAINS='localhost,localhost:3000,127.0.0.1,127.0.0.1:3000,127.0.0.1:8000,::1'
SESSION_DOMAIN=.localhost
Already tried
I also tried setting the correct timezone in config/app.php and I also changed the timezone inside the docker container (laravel sail) but the cookies still have the same data values and expiration times so that seems to be OK.
The same behaviour happens to me if I try to register a new user in a brand new installed Laravel 9 Project (which is configured as above) using Insomnia as REST Client:
The request/response timeline:
* Preparing request to http://localhost/register
* Current time is 2022-06-09T10:42:49.472Z
* Using default HTTP version
* Disable timeout
* Enable automatic URL encoding
* Enable SSL validation
* Enable cookie sending with jar of 2 cookies
* Hostname in DNS cache was stale, zapped
* Trying 127.0.0.1:80...
* Connected to localhost (127.0.0.1) port 80 (#21)
> POST /register HTTP/1.1
> Host: localhost
> User-Agent: insomnia/2022.3.0
> Cookie: laravel_session=eyJpdiI6IkpGdXZWRmh1WHdlc1F2VEpLVzllSFE9PSIsInZhbHVlIjoibk5JV0hmZHIzd1RpazRUOTJOOVBJZm1KNFZGUGlyaVJXTEk3NFl4YWVwSzRDNU5QQXh2Q1BrelNIWW55VWpEUTlXZmZaUjZPQUkrdjRDcnlCZUtkOENMMEhxOHVVWXhxcmFIdjdzRWh4dVgrLy9zRVhmOURFbFduR1hCcFIwcy8iLCJtYWMiOiJmZmZiZmI0MTk5OGNhZmRmMjFkZjgxMDk3MjgwMDBmYWFiNDA4YTZiYjQ1MjFkNjg0Mjk5MDRlMGEyNTU0NTUxIiwidGFnIjoiIn0%3D; XSRF-TOKEN=eyJpdiI6IkhtVjZrTWV2WC9KZFV0NWN4QUo2UVE9PSIsInZhbHVlIjoiQWJqQ2FuVHM1eENWZ212ZUZDNFZJVEErZk5ueGRUTnY3RFl3N2pJbEM4WEFTTE9UVFVWSXR1VkwvbkhhK1lqUkRySUJsWEtUT3RUWHI3UlcvTHpXSkNlNkNVZ3R2RXhkTVpWdWx2VmpZbDhPeWdTenVqVE5BWW1Rc1Qyb0t3L00iLCJtYWMiOiIwNTU2ZjgyMzdhNWU0Mjk1MzkyM2ZkN2Q4NWY2N2Y1MzAzYThlY2YxNmU2MzQyNTYxM2I3YjI2YjkyZjhiODZiIiwidGFnIjoiIn0%3D
> Content-Type: application/json
> Accept: application/json
> X-XSRF-TOKEN: eyJpdiI6IkhtVjZrTWV2WC9KZFV0NWN4QUo2UVE9PSIsInZhbHVlIjoiQWJqQ2FuVHM1eENWZ212ZUZDNFZJVEErZk5ueGRUTnY3RFl3N2pJbEM4WEFTTE9UVFVWSXR1VkwvbkhhK1lqUkRySUJsWEtUT3RUWHI3UlcvTHpXSkNlNkNVZ3R2RXhkTVpWdWx2VmpZbDhPeWdTenVqVE5BWW1Rc1Qyb0t3L00iLCJtYWMiOiIwNTU2ZjgyMzdhNWU0Mjk1MzkyM2ZkN2Q4NWY2N2Y1MzAzYThlY2YxNmU2MzQyNTYxM2I3YjI2YjkyZjhiODZiIiwidGFnIjoiIn0%3D
> Content-Length: 110
| {
| "name": "test",
| "email": "test7#local.de",
| "password": "test1234",
| "password_confirmation": "test1234"
| }
* Mark bundle as not supporting multiuse
< HTTP/1.1 419 unknown status
< Host: localhost
< Date: Thu, 09 Jun 2022 10:42:49 GMT
< Connection: close
< X-Powered-By: PHP/8.1.6
< Cache-Control: no-cache, private
< Date: Thu, 09 Jun 2022 10:42:49 GMT
< Content-Type: application/json
< Content-Length: 11025
* Replaced cookie laravel_session="eyJpdiI6IlhpSzV3SnJLOExyeXU0NGtaM0piZEE9PSIsInZhbHVlIjoiMkhsekNJYy80OTJHb3o2OWppZ2pSMDg2aHZuNTkzc1pYMXh2VDdHSW9XaUVPSlRkSkphZ013cnNEMW1CY1I1Zy9zNGpHTGtra0tEY1BQWGdhUlFUbWNzM3FJOVNqbTlNSEhxSXFSck1oWUlvbURvRFlYbW1oLytBbGJIUW1wYksiLCJtYWMiOiI1MGZjOGNhNTNmOTcxNTg1MjhkY2FmZjcwMWYwODBlZGE1NzYwZjU2MGJiNzRlZDk0NTU3YzBmZmUxZTVjYmNiIiwidGFnIjoiIn0%3D" for domain localhost, path /, expire 1654778569
< Set-Cookie: laravel_session=eyJpdiI6IlhpSzV3SnJLOExyeXU0NGtaM0piZEE9PSIsInZhbHVlIjoiMkhsekNJYy80OTJHb3o2OWppZ2pSMDg2aHZuNTkzc1pYMXh2VDdHSW9XaUVPSlRkSkphZ013cnNEMW1CY1I1Zy9zNGpHTGtra0tEY1BQWGdhUlFUbWNzM3FJOVNqbTlNSEhxSXFSck1oWUlvbURvRFlYbW1oLytBbGJIUW1wYksiLCJtYWMiOiI1MGZjOGNhNTNmOTcxNTg1MjhkY2FmZjcwMWYwODBlZGE1NzYwZjU2MGJiNzRlZDk0NTU3YzBmZmUxZTVjYmNiIiwidGFnIjoiIn0%3D; expires=Thu, 09 Jun 2022 12:42:49 GMT; Max-Age=7200; path=/; domain=.localhost; httponly; samesite=lax
* Received 10.8 KB chunk
* Closing connection 21
* Saved 1 cookie
The error message:
{
"message": "CSRF token mismatch.",
"exception": "Symfony\\Component\\HttpKernel\\Exception\\HttpException",
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php",
"line": 379,
"trace": [
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Exceptions/Handler.php",
"line": 353,
"function": "prepareException",
"class": "Illuminate\\Foundation\\Exceptions\\Handler",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Routing/Pipeline.php",
"line": 51,
"function": "render",
"class": "Illuminate\\Foundation\\Exceptions\\Handler",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 185,
"function": "handleException",
"class": "Illuminate\\Routing\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/View/Middleware/ShareErrorsFromSession.php",
"line": 49,
"function": "Illuminate\\Pipeline\\{closure}",
"class": "Illuminate\\Pipeline\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 180,
"function": "handle",
"class": "Illuminate\\View\\Middleware\\ShareErrorsFromSession",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Session/Middleware/StartSession.php",
"line": 121,
"function": "Illuminate\\Pipeline\\{closure}",
"class": "Illuminate\\Pipeline\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Session/Middleware/StartSession.php",
"line": 64,
"function": "handleStatefulRequest",
"class": "Illuminate\\Session\\Middleware\\StartSession",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 180,
"function": "handle",
"class": "Illuminate\\Session\\Middleware\\StartSession",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Cookie/Middleware/AddQueuedCookiesToResponse.php",
"line": 37,
"function": "Illuminate\\Pipeline\\{closure}",
"class": "Illuminate\\Pipeline\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 180,
"function": "handle",
"class": "Illuminate\\Cookie\\Middleware\\AddQueuedCookiesToResponse",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Cookie/Middleware/EncryptCookies.php",
"line": 67,
"function": "Illuminate\\Pipeline\\{closure}",
"class": "Illuminate\\Pipeline\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 180,
"function": "handle",
"class": "Illuminate\\Cookie\\Middleware\\EncryptCookies",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 116,
"function": "Illuminate\\Pipeline\\{closure}",
"class": "Illuminate\\Pipeline\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Routing/Router.php",
"line": 726,
"function": "then",
"class": "Illuminate\\Pipeline\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Routing/Router.php",
"line": 703,
"function": "runRouteWithinStack",
"class": "Illuminate\\Routing\\Router",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Routing/Router.php",
"line": 667,
"function": "runRoute",
"class": "Illuminate\\Routing\\Router",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Routing/Router.php",
"line": 656,
"function": "dispatchToRoute",
"class": "Illuminate\\Routing\\Router",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php",
"line": 167,
"function": "dispatch",
"class": "Illuminate\\Routing\\Router",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 141,
"function": "Illuminate\\Foundation\\Http\\{closure}",
"class": "Illuminate\\Foundation\\Http\\Kernel",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/TransformsRequest.php",
"line": 21,
"function": "Illuminate\\Pipeline\\{closure}",
"class": "Illuminate\\Pipeline\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/ConvertEmptyStringsToNull.php",
"line": 31,
"function": "handle",
"class": "Illuminate\\Foundation\\Http\\Middleware\\TransformsRequest",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 180,
"function": "handle",
"class": "Illuminate\\Foundation\\Http\\Middleware\\ConvertEmptyStringsToNull",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/TransformsRequest.php",
"line": 21,
"function": "Illuminate\\Pipeline\\{closure}",
"class": "Illuminate\\Pipeline\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/TrimStrings.php",
"line": 40,
"function": "handle",
"class": "Illuminate\\Foundation\\Http\\Middleware\\TransformsRequest",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 180,
"function": "handle",
"class": "Illuminate\\Foundation\\Http\\Middleware\\TrimStrings",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/ValidatePostSize.php",
"line": 27,
"function": "Illuminate\\Pipeline\\{closure}",
"class": "Illuminate\\Pipeline\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 180,
"function": "handle",
"class": "Illuminate\\Foundation\\Http\\Middleware\\ValidatePostSize",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Http/Middleware/PreventRequestsDuringMaintenance.php",
"line": 86,
"function": "Illuminate\\Pipeline\\{closure}",
"class": "Illuminate\\Pipeline\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 180,
"function": "handle",
"class": "Illuminate\\Foundation\\Http\\Middleware\\PreventRequestsDuringMaintenance",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Http/Middleware/HandleCors.php",
"line": 49,
"function": "Illuminate\\Pipeline\\{closure}",
"class": "Illuminate\\Pipeline\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 180,
"function": "handle",
"class": "Illuminate\\Http\\Middleware\\HandleCors",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Http/Middleware/TrustProxies.php",
"line": 39,
"function": "Illuminate\\Pipeline\\{closure}",
"class": "Illuminate\\Pipeline\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 180,
"function": "handle",
"class": "Illuminate\\Http\\Middleware\\TrustProxies",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 116,
"function": "Illuminate\\Pipeline\\{closure}",
"class": "Illuminate\\Pipeline\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php",
"line": 142,
"function": "then",
"class": "Illuminate\\Pipeline\\Pipeline",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Http/Kernel.php",
"line": 111,
"function": "sendRequestThroughRouter",
"class": "Illuminate\\Foundation\\Http\\Kernel",
"type": "->"
},
{
"file": "/var/www/html/public/index.php",
"line": 52,
"function": "handle",
"class": "Illuminate\\Foundation\\Http\\Kernel",
"type": "->"
},
{
"file": "/var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/resources/server.php",
"line": 16,
"function": "require_once"
}
]
}
I don't know how to investigate any further.

I misinterpreted my error logs and found that there is another small difference using Axios and Fetch API:
Axios seems to decode the X-XSRF-TOKEN whereas Fetch API does not.
So this example token is sent by Fetch API:
eyJpdiI6IkRScW9GNGtIbndWWFdKbzRiN0VWVkE9PSIsInZhbHVlIjoiNUNuQStiZGt0Y3l0cXhReThHSEJxbCsxRmZvbFFHKzhQV3ArSlg0cjVQVm5qSDZoQ3ZsSERnUTREUXRvczdMOHhYSHFqbm5FUjd2dFpGMlN4bU81NWJ5SWpmem5BQi9vRmJBRFZZWmFSZFlqcHNxbTZ5N1Z0cGJzSmMwcUFRaXUiLCJtYWMiOiI4MjM1MTQ2ODExNzhlY2ExNDk1NDhhOWEwNzE0OWJlMzViOGQxNDJhMTY0YTI2NzYwMThjMzQ5ODVmMDYwMjk1IiwidGFnIjoiIn0%3D
And this example token is sent by Axios:
eyJpdiI6IisydDZOOFJoREp5ZnZudUtjRk1teXc9PSIsInZhbHVlIjoiV1dQdjJDZlNrcW43Zlg4TW1yRFdjOVJWVnJkaC9CZndxejJLQ3JEUkJIRXJ3Z2pNb2pxSUJYN0Y2RDBxZ1hKd01mNHF6empsRkFIeEFOSkJKbi8vT0hWOFBYMDdlMkZybzBZdllJQlBFa1lHTytZd1E0aU9vL2pOM1ZRZWwxV0ciLCJtYWMiOiI3NTczZGJiMjg5MWZmOTUzMjhiMTZhNjAxM2ZiZmVjODVjYjc2MGRiMGJkMTFkOGYzOWQzYWQ5MjI5YWIwOTA5IiwidGFnIjoiIn0=
There is a very small difference at the end of the token string (= vs. %3D).
Laravel itself sends the Token value URIEncoded (with %3D) but seems to expect the token with = at the end.
There is nothing about that in the docs but this issue kept me searching for days and was not that obvious.
I changed my code to:
export const useLogin = async (email, password) => {
const config = useRuntimeConfig()
const tokenResponse = await $fetch(config.baseURL + '/sanctum/csrf-cookie', {
method: 'GET',
credentials: 'include'
})
const token = decodeURIComponent(getCookie('XSRF-TOKEN')) // <---- CHANGED
console.log(token)
const loginResponse = await $fetch(config.baseURL + '/login', {
method: 'POST',
credentials: 'include',
headers: {
'X-XSRF-TOKEN': token,
'Accept': 'application/json, text/plain, */*',
'Content-Type': 'application/json',
'X-Requested-With': 'XMLHttpRequest'
},
body: {
"email": email,
"password": password
}
})
}
And now the login is working using the standard Fetch API.
I hope this helps someone else debugging their login flow.
Greetings.

This is happening due to page expiration as it is post request. Can you add these below credentials in .env file and run php artisan config:cache
SESSION_DOMAIN=localhost
SANCTUM_STATEFUL_DOMAINS=localhost
Then see the result. YOu should also pass headers token as X-CSRF-TOKEN

Related

Install `laravel` error `could not find driver`

Install laravel error could not find driver
问题:
The version of laravel is 5.8.38
The version of php is 7.4.3
The version of mysql is 8.0.21
I get the error could not find driver when installing laravel
The mysql database has been configured, and the data has been migrated to the mysql database. It should not be reported that the driver cannot be found.
{
"message": "could not find driver (SQL: select * from `my_admin` where `mobile` = 18912345678 order by `id` asc limit 1)",
"exception": "Illuminate\\Database\\QueryException",
"file": "/home/ubuntu/ygd/api/vendor/laravel/framework/src/Illuminate/Database/Connection.php",
"line": 664,
"trace": [
{
"file": "/home/ubuntu/ygd/api/vendor/laravel/framework/src/Illuminate/Database/Connection.php",
"line": 624,
"function": "runQueryCallback",
"class": "Illuminate\\Database\\Connection",
"type": "->"
},
{
"file": "/home/ubuntu/ygd/api/vendor/laravel/framework/src/Illuminate/Database/Connection.php",
"line": 333,
"function": "run",
"class": "Illuminate\\Database\\Connection",
"type": "->"
},
{
"file": "/home/ubuntu/ygd/api/vendor/laravel/framework/src/Illuminate/Database/Query/Builder.php",
"line": 2130,
"function": "select",
"class": "Illuminate\\Database\\Connection",
"type": "->"
}
...
]
}
You should use php -i |grep mysqlnd to check if the mysql driver is enabled, not php -m
In addition, about the PHP operating environment, if it is a local development environment
homestead is recommended under windows
valet is recommended under macOS
The server environment recommends lnmp one-click installation package

Where can Laravel route middleware be used besides routes configuration?

I was cleaning my Kernel.php from unused route middleware when I noticed the following declaration:
'can' => \Illuminate\Auth\Middleware\Authorize::class,
I double-checked Kernel.php and all the routes: the can middleware was not used anywhere. So I decided to delete it. But the next moment my test suite failed with the following error:
{
"message": "Target class [can] does not exist.",
"exception": "Illuminate\\Contracts\\Container\\BindingResolutionException",
"file": "/app/vendor/laravel/framework/src/Illuminate/Container/Container.php",
"line": 875,
"trace": [
{
"file": "/app/vendor/laravel/framework/src/Illuminate/Container/Container.php",
"line": 754,
"function": "build",
"class": "Illuminate\\Container\\Container",
"type": "->"
},
{
"file": "/app/vendor/laravel/framework/src/Illuminate/Foundation/Application.php",
"line": 841,
"function": "resolve",
"class": "Illuminate\\Container\\Container",
"type": "->"
},
{
"file": "/app/vendor/laravel/framework/src/Illuminate/Container/Container.php",
"line": 692,
"function": "resolve",
"class": "Illuminate\\Foundation\\Application",
"type": "->"
},
{
"file": "/app/vendor/laravel/framework/src/Illuminate/Foundation/Application.php",
"line": 826,
"function": "make",
"class": "Illuminate\\Container\\Container",
"type": "->"
},
{
"file": "/app/vendor/laravel/framework/src/Illuminate/Pipeline/Pipeline.php",
"line": 156,
"function": "make",
"class": "Illuminate\\Foundation\\Application",
"type": "->"
},
...
I wasn't able to debug this yet, but it looks like something is trying to construct the can via the service container.
So the question is: where else can the $routeMiddleware declarations be used besides the application routing? How do you know if a given route middleware is used or not by the framework?
I think it may be related to $user->can() calls but I don't get it what does it have to do with named middleware declarations.
The User Model by default extends the Authenticatable user model class which implements the:
AuthenticatableContract,
AuthorizableContract,
CanResetPasswordContract interfaces.
Those interfaces deals with can middleware. This is way you received that error message.
This middleware is used by the AuthorizesRequests trait here.

How to register multiple service instances in consul on one machine

I have a consul running locally on a dev machine. I also have one golang service running on two different ports on the same machine. Is there a way to register them as one service but two instances in consul using golang API (for example, is it possible to specify the node name when registering)?
Here's a very basic example which registers two instances of a service named my-service. Each instance is configured to listen on a different port, 8080 and 8081 respectively.
The key thing to note is that the service instances are also registered with a unique service ID in order to disambiguate between instance A and instance B of my-service which are running on the same agent.
package main
import (
"fmt"
"github.com/hashicorp/consul/api"
)
func main() {
// Get a new client
client, err := api.NewClient(api.DefaultConfig())
if err != nil {
panic(err)
}
service_name := "my-service"
service_ports := [2]int{8080, 8081}
for idx, port := range service_ports {
svc_reg := &api.AgentServiceRegistration{
ID: fmt.Sprintf("%s-%d", service_name, idx),
Name: service_name,
Port: port,
}
client.Agent().ServiceRegister(svc_reg)
}
}
After running go mod init consul-register (or any module name), and executing the code with go run main.go, you can see the service has been registered in the catalog.
$ consul catalog services
consul
my-service
Both service instances are correctly being returned for service discovery queries over DNS or HTTP.
$ dig #127.0.0.1 -p 8600 -t SRV my-service.service.consul +short
1 1 8080 b1000.local.node.dc1.consul.
1 1 8081 b1000.local.node.dc1.consul.
$ curl localhost:8500/v1/health/service/my-service
[
{
"Node": {
"ID": "11113853-a8e0-5787-7482-538078db855a",
"Node": "b1000.local",
"Address": "127.0.0.1",
"Datacenter": "dc1",
"TaggedAddresses": {
"lan": "127.0.0.1",
"lan_ipv4": "127.0.0.1",
"wan": "127.0.0.1",
"wan_ipv4": "127.0.0.1"
},
"Meta": {
"consul-network-segment": ""
},
"CreateIndex": 11,
"ModifyIndex": 13
},
"Service": {
"ID": "my-service-0",
"Service": "my-service",
"Tags": [],
"Address": "",
"Meta": null,
"Port": 8080,
"Weights": {
"Passing": 1,
"Warning": 1
},
"EnableTagOverride": false,
"Proxy": {
"Mode": "",
"MeshGateway": {},
"Expose": {},
"TransparentProxy": {}
},
"Connect": {},
"CreateIndex": 14,
"ModifyIndex": 14
},
"Checks": [
{
"Node": "b1000.local",
"CheckID": "serfHealth",
"Name": "Serf Health Status",
"Status": "passing",
"Notes": "",
"Output": "Agent alive and reachable",
"ServiceID": "",
"ServiceName": "",
"ServiceTags": [],
"Type": "",
"Definition": {},
"CreateIndex": 11,
"ModifyIndex": 11
}
]
},
{
"Node": {
"ID": "11113853-a8e0-5787-7482-538078db855a",
"Node": "b1000.local",
"Address": "127.0.0.1",
"Datacenter": "dc1",
"TaggedAddresses": {
"lan": "127.0.0.1",
"lan_ipv4": "127.0.0.1",
"wan": "127.0.0.1",
"wan_ipv4": "127.0.0.1"
},
"Meta": {
"consul-network-segment": ""
},
"CreateIndex": 11,
"ModifyIndex": 13
},
"Service": {
"ID": "my-service-1",
"Service": "my-service",
"Tags": [],
"Address": "",
"Meta": null,
"Port": 8081,
"Weights": {
"Passing": 1,
"Warning": 1
},
"EnableTagOverride": false,
"Proxy": {
"Mode": "",
"MeshGateway": {},
"Expose": {},
"TransparentProxy": {}
},
"Connect": {},
"CreateIndex": 15,
"ModifyIndex": 15
},
"Checks": [
{
"Node": "b1000.local",
"CheckID": "serfHealth",
"Name": "Serf Health Status",
"Status": "passing",
"Notes": "",
"Output": "Agent alive and reachable",
"ServiceID": "",
"ServiceName": "",
"ServiceTags": [],
"Type": "",
"Definition": {},
"CreateIndex": 11,
"ModifyIndex": 11
}
]
}
]

Laravel managing Personal Access Tokens

I'm following Laravel documentation to "Managing Personal Access Tokens"
I created a TestController try to create a personal access token.
public function getToken()
{
$user = \App\User::find(1);
// Creating a token without scopes...
$token = $user->createToken('3page')->accessToken;
dd($token);
}
I can get the $user but get error when createToken
{
"message": "Trying to get property 'id' of non-object",
"exception": "ErrorException",
"file": "/home/vagrant/code/test/vendor/laravel/passport/src/PersonalAccessTokenFactory.php",
"line": 98,
"trace": [
{
"file": "/home/vagrant/code/test/vendor/laravel/passport/src/PersonalAccessTokenFactory.php",
"line": 98,
"function": "handleError",
"class": "Illuminate\\Foundation\\Bootstrap\\HandleExceptions",
"type": "->"
},
Please advice!
Did you run php artisan passport:client --personal command?
You have to set the --personal flag in order to use your code.
Reference: https://laravel.com/docs/6.x/passport#creating-a-personal-access-client

Registering Multiple Same-Host Services

I am using the Consul API to register a local web-service running on various ports on my local machine. My end-goal is to be able to run multiple backends and load balance against them on different ports.
I am running a local Consul server of one node for development in a Vagrant VM. I have registered the first instance of my service:
{
"Node": {
"ID": "49d3be4b-5ee5-5f0f-e145-dcb1782e5b4b",
"Node": "localhost",
"Address": "127.0.0.1",
"Datacenter": "dc1",
"TaggedAddresses": {
"lan": "127.0.0.1",
"wan": "127.0.0.1"
},
"Meta": {
"consul-network-segment": ""
},
"CreateIndex": 5,
"ModifyIndex": 6
},
"Services": {
"consul": {
"ID": "consul",
"Service": "consul",
"Tags": [],
"Address": "",
"Port": 8300,
"EnableTagOverride": false,
"CreateIndex": 5,
"ModifyIndex": 5
},
"rusty": {
"ID": "rusty",
"Service": "rusty",
"Tags": [
"rusty",
"rust"
],
"Address": "127.0.0.1",
"Port": 8001,
"EnableTagOverride": false,
"CreateIndex": 247,
"ModifyIndex": 491
}
}
}
You can see my service, rusty, registered on port 8001. The strange thing is that when I register the same service on a different port, Consul supersedes port 8001 with the new service port.
Is there not a way to run multiple backends for a service on different ports on the same host?
Try to check that you are registering services with different IDs. For complete info see the parameters for /agent/service/register endpoint.
Here is an example with two rusty service instances with different IDs rusty1 and rusty2
{
"Node": {
"ID": "eff2fae3-6ee5-5de7-bf1a-c041992a1d6a",
"Node": "FB20160707",
"Address": "192.168.1.66",
"Datacenter": "dc1",
"TaggedAddresses": {
"lan": "192.168.1.66",
"wan": "192.168.1.66"
},
"Meta": {},
"CreateIndex": 5,
"ModifyIndex": 6
},
"Services": {
"consul": {
"ID": "consul",
"Service": "consul",
"Tags": [],
"Address": "",
"Port": 8300,
"EnableTagOverride": false,
"CreateIndex": 5,
"ModifyIndex": 5
},
"rusty1": {
"ID": "rusty1",
"Service": "rusty",
"Tags": [],
"Address": "10.10.10.10",
"Port": 8001,
"EnableTagOverride": false,
"CreateIndex": 16,
"ModifyIndex": 28
},
"rusty2": {
"ID": "rusty2",
"Service": "rusty",
"Tags": [],
"Address": "10.10.10.10",
"Port": 8002,
"EnableTagOverride": false,
"CreateIndex": 19,
"ModifyIndex": 29
}
}
}
As per my comment to #ruslan-sennov, if the services section looked like this (the ID for each instance of the rusty service is made unique by adding the port, but the name is kept as rusty):
"Services": {
"consul": {
"ID": "consul",
"Service": "consul",
"Tags": [],
"Address": "",
"Port": 8300,
"EnableTagOverride": false,
"CreateIndex": 5,
"ModifyIndex": 5
},
"rusty": {
"ID": "rusty:8001",
"Service": "rusty",
"Tags": [
"rusty",
"rust"
],
"Address": "127.0.0.1",
"Port": 8001,
"EnableTagOverride": false,
"CreateIndex": 247,
"ModifyIndex": 491
},
"rusty": {
"ID": "rusty:8002",
"Service": "rusty",
"Tags": [
"rusty",
"rust"
],
"Address": "127.0.0.1",
"Port": 8002,
"EnableTagOverride": false,
"CreateIndex": 247,
"ModifyIndex": 491
}
}
This then means you can query the rusty service with a SRV query and get detail on which ports are available:
dig #127.0.0.1 rusty.service.consul SRV
; <<>> DiG 9.11.3 <<>> rusty.service.consul SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56091
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 52, AUTHORITY: 0, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rusty.service.consul. IN SRV
;; ANSWER SECTION:
rusty.service.consul. 0 IN SRV 1 1 8001 FB20160707.node.dc1.consul.
rusty.service.consul. 0 IN SRV 1 1 8002 FB20160707.node.dc1.consul.
If you also change the names to be unique (rusty1 and rusty2 as suggested by Ruslan) you lose this querying ability.
I know this is late to answer this, but hope this would help someone.
As per Spring Cloud Consul docs, Add this to bootstrap.yml.
spring:
cloud:
consul:
discovery:
instanceId: ${spring.application.name}:${vcap.application.instance_id:${spring.application.instance_id:${random.value}}}

Resources