-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat: CHK-3744 expose checkout authenticated ecommerce endpoint #2858
feat: CHK-3744 expose checkout authenticated ecommerce endpoint #2858
Conversation
…nt' of https://github.com/pagopa/pagopa-infra into CHK-3744-expose-checkout-authenticated-ecommerce-endpoint
src/domains/ecommerce-app/api/ecommerce-checkout/v3/_base_policy.xml.tpl
Outdated
Show resolved
Hide resolved
</set-header> | ||
</send-request> | ||
<choose> | ||
<when condition="@(((int)((IResponse)context.Variables["checkSessionResponse"]).StatusCode) != 200)"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason we don't propagate downstream dependency status code here? If we get a 5xx we would give a 401, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In other authenticated flux, we reduce all errors in 401. I did the same here.
Yes, all code except 200 will return a 401.
Do you think it is better to return downstream dependency result code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering if returning a 401 in case of a 5xx could be a problem for the frontend, we would show invalid token error page instead of generic error page, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, we will show an invalid token message in place of a generic error page.
It could be useful showing a generic error message, but it could be a little confusing for the user.
Is the payment api that results in 5xx or is the token validation?
Anyway I will add 4xx and 5xx status code but we should be able to manage this situation in a right way in checkout-fe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done here 35b020a
<outbound> | ||
<base /> | ||
<!-- APM test START --> | ||
<set-variable name="allowedIps" value="PLACEHOLDER1,PLACEHOLDER2" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe this (more or less :-) )feature flag by ip, is required for this version? We could add in a dedicated PR if needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In order to manage dedicated payment method for restricted set of ips I paste this policy here. Anyway I'm going to remove it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done here cc468cd
<set-variable name="rptId" value="@{ | ||
return context.Request.MatchedParameters["rpt_id"]; | ||
}" /> | ||
<choose> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it possible to move this logic in base policy? I think it is safe for all API because there is when condition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we have an rptId param in all request?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rptId
is not present in all APIs, but with the when
condition it is set only when present. This way, we avoid having a dedicated policy for a specific API, but we should consider the trade-off. It's an extra operation, although very light, but applied to all APIs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, it's a suggestion, we might not do it after all :-)
<policies> | ||
<inbound> | ||
<rate-limit-by-key | ||
calls="150" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it possible to move this logic in base policy? this rate limit is different considering base policy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was a misprint from copy/paste action. Removed here 8e7e6f7
</choose> | ||
|
||
<set-variable name="pdvToken" value="@(((IResponse)context.Variables["pdv-token"]).Body.As<JObject>())" /> | ||
<set-variable name="emailToken" value="@((string)((JObject)context.Variables["pdvToken"])["token"])" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
at this level, we add tokenization of fiscalCode and pass it to backend (as header x-user-id)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, should I do this in this pr or in a dedicated one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, it's a dedicated PR :-)
api_name = "${local.project}-ecommerce-checkout-api-v3" | ||
api_management_name = local.pagopa_apim_name | ||
resource_group_name = local.pagopa_apim_rg | ||
operation_id = "newTransaction" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
operation_id = "newTransaction" | |
operation_id = "newTransactionV3" |
in order to avoid conflict with operationId related v1, v2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done here 8e7e6f7
api_name = "${local.project}-ecommerce-checkout-api-v3" | ||
resource_group_name = local.pagopa_apim_rg | ||
api_management_name = local.pagopa_apim_name | ||
operation_id = "createSession" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done here 8e7e6f7
api_name = "${local.project}-ecommerce-checkout-api-v3" | ||
resource_group_name = local.pagopa_apim_rg | ||
api_management_name = local.pagopa_apim_name | ||
operation_id = "getAllPaymentMethods" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done here 8e7e6f7
…and with counter key referring to the auth token
…ionId in openapi definition and in base policy clustering. Update readme
aeb2a57
🎉 This PR is included in version 1.426.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
Add ecommerce for checkout endpoints authorized via auth service token
List of changes
Add 4 endpoints:
All these endpoints use auth token validate to authenticate api and discard recaptcha (where present)
Token validation is executed in the base policy.
The new apis, has the same schema for request and response, except for recaptcha in query param and the auth token in auth header. The new apis path, starts with
auth/
prefix. This prefix is needed to avoid confusion with the twins endpoints of previous version for guest flux.Motivation and context
This PR enable authenticated flux in checkout web portal
Type of changes
Does this introduce a change to production resources with possible user impact?
Does this introduce an unwanted change on infrastructure? Check terraform plan execution result
Other information
If PR is partially applied, why? (reserved to mantainers)