-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot use Authorizer ARN #109
Comments
Hi @defendertx , yes you're right. External references should not be altered but just used as is. I recently merged PR #102 and think that addresses exactly your problem. Can you try with the master branch of the project and confirm that it works for you?
|
Master works as expected. Thanks! |
Good to know. I'll do a release soon. |
I've tried master to avoid this issue, and have not had any success as yet. my authorizer arn is serverless custom var, in turn is a collections of serverless vars forming a string, some of which are ${cf.:authorizer-arn} type vars. Im wondering if its the cf import that may be throughing this off. |
@ColeTMNZ The CF resolution in Serverless should resolve before the alias plugin is used. But could you do a |
Heres my authorizer resource. Is it possibly the join that's throwing errors?
|
@ColeTMNZ Yes it is. I think we have to improve the detection algorithm for external authorizers, because right now it seems to miss this case. |
I believe I confirmed this worked. My stack gets a lot further in the creation process, and fails on other unrelated issues now. (alias & domain manager, alias and step functions) I checked the cloud formation template and the Authorizer Resources were correctly created. (before being removed due to other mentioned errors) |
I'll target this for 1.7+. |
I'm having an issue where I'm attempting to use an ARN for my authorizer (all of my services share a common authorizer) but the plugin is inserting
${stageVariables.SERVERLESS_ALIAS}
where it does not belong, in front of the ARN. Is this a bug or do I need to do something special in the yaml to tell serverless-aws-alias to not attempt to modify the ARN? I believe the preferred behavior would be if an ARN was provided for the authorizer to pass it through unmodified because it exists outside of this stack.The text was updated successfully, but these errors were encountered: