OpenLiberty / open-liberty

Open Liberty is a highly composable, fast to start, dynamic application server runtime environment
https://openliberty.io
Eclipse Public License 2.0
1.16k stars 599 forks source link

Allow the SameSite attribute to be set on a Cookie #10086

Closed pnicolucci closed 4 years ago

pnicolucci commented 4 years ago

We need to investigate and design a way to add the SameSite attribute to cookies added via the Servlet API by applications as well as the session Cookie created by Open Liberty. In addition we should investigate any other cookies that we set as part of the runtime and determine if we need to add a configuration for SameSite to those cookies as well.

Jakarta Servlet Spec Issue: https://github.com/eclipse-ee4j/servlet-api/issues/175

RFE Link: https://www.ibm.com/developerworks/rfe/execute?use_case=viewChangeRequest&CR_ID=119022

Current options documented here: https://www.ibm.com/support/pages/browser-changes-samesite-cookie-handling-and-websphere-application-server

UFO: https://ibm.box.com/s/oeiwm7h19iy9is55uvx05yipb4dpvrzb


List of Steps to complete or get approvals / sign-offs for Onboarding to the Liberty release (GM date)

Instructions:


TARGET COMPLETION DATE Before Development Starts or 8 weeks before Onboarding

chirp1 commented 4 years ago

On February 18, Paul and I slacked about the documentation requirements. Any updates in the doc will be in Autogen. The usual blog post will also be published. So, ID has no requirement to write documentation. Approving this epic.

gscottj commented 4 years ago

This feature has no user interface except for configuration parameters. No accessibility testing required.

pnicolucci commented 4 years ago

Serviceability Approval Comment - Please answer the following questions for serviceability approval:

  1. UFO -- does the UFO identify the most likely problems customers will see and identify how the feature will enable them to diagnose and solve those problems without resorting to raising a PMR? Have these issues been addressed in the implementation?

Yes the UFO does identify the most likely problems customers will see. We've been very descriptive in our configuration Warning messages for invalid configuration. The UFO lists each of these Warnings and they have been implemented and tested in the implementation.

  1. Test and Demo -- As part of the serviceability process we're asking feature teams to test and analyze common problem paths for serviceability and demo those problem paths to someone not involved in the development of the feature (eg. L2, test team, or another development team).
    a) What problem paths were tested and demonstrated?

    Demonstrated Session and HttpEndpoint SameSite configuration, both as a standalone configuration and when configured by themselves. Misconfigured values and expected results were discussed and shown in tracing. Tracing covered both transport level tracing and warning messages that do not require tracing to be enabled.>

b) Who did you demo to?

Bill Lucy and Volodymyr Siedlecki from WAS Web Tier development.

c) Do the people you demo'd to agree that the serviceability of the demonstrated problem scenarios is sufficient to avoid PMRs for any problems customers are likely to encounter, or that L2 should be able to quickly address those problems without need to engage L3?

They responded with, "The new messages added on the problem paths are well thought out and should be sufficient for customers to address configuration problems on their own."

  1. SVT -- SVT team is often the first team to try new features and often encounters problems setting up and using them. Note that we're not expecting SVT to do full serviceability testing -- just to sign-off on the serviceability of the problem paths they encountered. a) Who conducted SVT tests for this feature? - Brian Hanczaryk b) Do they agree that the serviceability of the problems they encountered is sufficient to avoid PMRs, or that L2 should be able to quickly address those problems without need to engage L3?

Brian Hanczaryk 8:46 PM b) Yes, I agree that serviceability of any problems was sufficient to avoid PMRs or that L2 could quickly address any issues without the need to engage L3.

  1. Which L2 / L3 queues will handle PMRs for this feature? Ensure they are present in the contact reference file and in the queue contact summary, and that the respective L2/L3 teams know they are supporting it. Ask Don Bourne if you need links or more info.

L2: WAS: L2 WEB Team L3: WAS L3:Security / WAS L3: WebContainer L2/L3 Informed -> I reached out to WEB team member to share with the larger team. Queue Contact Summary / Contact Reference File -> In my opinion nothing new to add here, no additional components were added as part of this feature it just has new metaType in the httpEndpoint,httpSession, and webAppSecurity.

skasund commented 4 years ago

No STE is needed. I've approved the feature.

pnicolucci commented 4 years ago

I've opened a GA blog post issue which is linked to this EPIC as well as a stand alone blog post with additional details : https://github.com/OpenLiberty/blogs/issues/288

pnicolucci commented 4 years ago

All approvals are completed, closing.