laravel passport invalid token during deployment on AWS
My setup is like the following:
I have a frontend written in Vue.js, a API in Laravel 5.6 and the infrastructure on AWS. Everything runs in docker containers. We have 4 API containers and a Load Balancer between Frontend and API. The authentication works with Laravel Passport v5 and bearer tokens.
Basically everything works fine and authentication is successful.
But when we deploy a new version of the API it comes to the following situation:
2 API instances have version 1 and the other 2 API instances have version 2.
This is intended, because we want to have continuous deployment with no downtimes. After some time the 2 v1 instances also are replaced by the new v2 instances. All instances use the same database.
Unfortunately during this time window, the authentication does not work anymore. It seems like the Frontend makes a few request to the API with a correct new token. The Load Balancer distributes some of the requests to v1 instances some to v2 isntances. The requests to v2 instances are successful, the ones to v1 instances are not (401 unauthorized).
My question: How does passport validate the bearer token? Why cant a v1 instance validate a token which was generated by v2 instance and vice versa? What can I possibly oversee that differs between the instances and influence passport even though they all use the same database?
laravel amazon-web-services laravel-5.6 laravel-passport
add a comment |
My setup is like the following:
I have a frontend written in Vue.js, a API in Laravel 5.6 and the infrastructure on AWS. Everything runs in docker containers. We have 4 API containers and a Load Balancer between Frontend and API. The authentication works with Laravel Passport v5 and bearer tokens.
Basically everything works fine and authentication is successful.
But when we deploy a new version of the API it comes to the following situation:
2 API instances have version 1 and the other 2 API instances have version 2.
This is intended, because we want to have continuous deployment with no downtimes. After some time the 2 v1 instances also are replaced by the new v2 instances. All instances use the same database.
Unfortunately during this time window, the authentication does not work anymore. It seems like the Frontend makes a few request to the API with a correct new token. The Load Balancer distributes some of the requests to v1 instances some to v2 isntances. The requests to v2 instances are successful, the ones to v1 instances are not (401 unauthorized).
My question: How does passport validate the bearer token? Why cant a v1 instance validate a token which was generated by v2 instance and vice versa? What can I possibly oversee that differs between the instances and influence passport even though they all use the same database?
laravel amazon-web-services laravel-5.6 laravel-passport
add a comment |
My setup is like the following:
I have a frontend written in Vue.js, a API in Laravel 5.6 and the infrastructure on AWS. Everything runs in docker containers. We have 4 API containers and a Load Balancer between Frontend and API. The authentication works with Laravel Passport v5 and bearer tokens.
Basically everything works fine and authentication is successful.
But when we deploy a new version of the API it comes to the following situation:
2 API instances have version 1 and the other 2 API instances have version 2.
This is intended, because we want to have continuous deployment with no downtimes. After some time the 2 v1 instances also are replaced by the new v2 instances. All instances use the same database.
Unfortunately during this time window, the authentication does not work anymore. It seems like the Frontend makes a few request to the API with a correct new token. The Load Balancer distributes some of the requests to v1 instances some to v2 isntances. The requests to v2 instances are successful, the ones to v1 instances are not (401 unauthorized).
My question: How does passport validate the bearer token? Why cant a v1 instance validate a token which was generated by v2 instance and vice versa? What can I possibly oversee that differs between the instances and influence passport even though they all use the same database?
laravel amazon-web-services laravel-5.6 laravel-passport
My setup is like the following:
I have a frontend written in Vue.js, a API in Laravel 5.6 and the infrastructure on AWS. Everything runs in docker containers. We have 4 API containers and a Load Balancer between Frontend and API. The authentication works with Laravel Passport v5 and bearer tokens.
Basically everything works fine and authentication is successful.
But when we deploy a new version of the API it comes to the following situation:
2 API instances have version 1 and the other 2 API instances have version 2.
This is intended, because we want to have continuous deployment with no downtimes. After some time the 2 v1 instances also are replaced by the new v2 instances. All instances use the same database.
Unfortunately during this time window, the authentication does not work anymore. It seems like the Frontend makes a few request to the API with a correct new token. The Load Balancer distributes some of the requests to v1 instances some to v2 isntances. The requests to v2 instances are successful, the ones to v1 instances are not (401 unauthorized).
My question: How does passport validate the bearer token? Why cant a v1 instance validate a token which was generated by v2 instance and vice versa? What can I possibly oversee that differs between the instances and influence passport even though they all use the same database?
laravel amazon-web-services laravel-5.6 laravel-passport
laravel amazon-web-services laravel-5.6 laravel-passport
edited Nov 14 '18 at 10:15
Phil
asked Nov 14 '18 at 9:43
PhilPhil
6519
6519
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
We have solved the problem and I explain it for those of you who are interested in:
The problem is, that as part of our deployment process we always call the artisan command "php artisan passport:keys" in order to make passport work in the new docker container.
If you have a closer look at this command, it generates 2 files:
oauth-private.key and oauth-public.key
These files are crucial for the generation of bearer tokens. The thing is, if you have multiple API docker containers with different oauth-files, they cannot validate the tokens of each other.
So the solution is, to change the deployment and always deploy the same oauth-files.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53297111%2flaravel-passport-invalid-token-during-deployment-on-aws%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
We have solved the problem and I explain it for those of you who are interested in:
The problem is, that as part of our deployment process we always call the artisan command "php artisan passport:keys" in order to make passport work in the new docker container.
If you have a closer look at this command, it generates 2 files:
oauth-private.key and oauth-public.key
These files are crucial for the generation of bearer tokens. The thing is, if you have multiple API docker containers with different oauth-files, they cannot validate the tokens of each other.
So the solution is, to change the deployment and always deploy the same oauth-files.
add a comment |
We have solved the problem and I explain it for those of you who are interested in:
The problem is, that as part of our deployment process we always call the artisan command "php artisan passport:keys" in order to make passport work in the new docker container.
If you have a closer look at this command, it generates 2 files:
oauth-private.key and oauth-public.key
These files are crucial for the generation of bearer tokens. The thing is, if you have multiple API docker containers with different oauth-files, they cannot validate the tokens of each other.
So the solution is, to change the deployment and always deploy the same oauth-files.
add a comment |
We have solved the problem and I explain it for those of you who are interested in:
The problem is, that as part of our deployment process we always call the artisan command "php artisan passport:keys" in order to make passport work in the new docker container.
If you have a closer look at this command, it generates 2 files:
oauth-private.key and oauth-public.key
These files are crucial for the generation of bearer tokens. The thing is, if you have multiple API docker containers with different oauth-files, they cannot validate the tokens of each other.
So the solution is, to change the deployment and always deploy the same oauth-files.
We have solved the problem and I explain it for those of you who are interested in:
The problem is, that as part of our deployment process we always call the artisan command "php artisan passport:keys" in order to make passport work in the new docker container.
If you have a closer look at this command, it generates 2 files:
oauth-private.key and oauth-public.key
These files are crucial for the generation of bearer tokens. The thing is, if you have multiple API docker containers with different oauth-files, they cannot validate the tokens of each other.
So the solution is, to change the deployment and always deploy the same oauth-files.
answered Dec 3 '18 at 14:18
PhilPhil
6519
6519
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53297111%2flaravel-passport-invalid-token-during-deployment-on-aws%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown