Skip to content
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

Merged

Conversation

ciuffagianluca
Copy link
Contributor

@ciuffagianluca ciuffagianluca commented Mar 4, 2025

Add ecommerce for checkout endpoints authorized via auth service token

List of changes

Add 4 endpoints:

  • post session
  • post transaction
  • get payment methods
  • get payment request

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

  • Add new resources
  • Update configuration to existing resources
  • Remove existing resources

Does this introduce a change to production resources with possible user impact?

  • Yes, users may be impacted applying this change
  • No

Does this introduce an unwanted change on infrastructure? Check terraform plan execution result

  • Yes
  • No

Other information


If PR is partially applied, why? (reserved to mantainers)

@ciuffagianluca ciuffagianluca changed the title [CHK-3744] expose checkout authenticated ecommerce endpoint (chore) CHK-3744: expose checkout authenticated ecommerce endpoint Mar 5, 2025
@ciuffagianluca ciuffagianluca marked this pull request as ready for review March 5, 2025 11:22
@ciuffagianluca ciuffagianluca requested review from a team as code owners March 5, 2025 11:22
@ciuffagianluca ciuffagianluca changed the title (chore) CHK-3744: expose checkout authenticated ecommerce endpoint feat: CHK-3744: expose checkout authenticated ecommerce endpoint Mar 5, 2025
@ciuffagianluca ciuffagianluca changed the title feat: CHK-3744: expose checkout authenticated ecommerce endpoint feat: CHK-3744 expose checkout authenticated ecommerce endpoint Mar 5, 2025
</set-header>
</send-request>
<choose>
<when condition="@(((int)((IResponse)context.Variables["checkSessionResponse"]).StatusCode) != 200)">
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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" />
Copy link
Contributor

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

Copy link
Contributor Author

@ciuffagianluca ciuffagianluca Mar 6, 2025

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.

Copy link
Contributor Author

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>
Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor

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"
Copy link
Contributor

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?

Copy link
Contributor Author

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"])" />
Copy link
Contributor

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)?

Copy link
Contributor Author

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?

Copy link
Contributor

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"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
operation_id = "newTransaction"
operation_id = "newTransactionV3"

in order to avoid conflict with operationId related v1, v2

Copy link
Contributor Author

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"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

Copy link
Contributor Author

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"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done here 8e7e6f7

infantesimone
infantesimone previously approved these changes Mar 6, 2025
CianoDanilo
CianoDanilo previously approved these changes Mar 6, 2025
EmanueleBVtech
EmanueleBVtech previously approved these changes Mar 6, 2025
@ciuffagianluca ciuffagianluca merged commit 54f3bb5 into main Mar 6, 2025
5 of 6 checks passed
@ciuffagianluca ciuffagianluca deleted the CHK-3744-expose-checkout-authenticated-ecommerce-endpoint branch March 6, 2025 13:36
Copy link

github-actions bot commented Mar 6, 2025

🎉 This PR is included in version 1.426.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants