Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-8997

Make flash attributes use cookie to enable stateless webapp

    Details

    • Type: Improvement
    • Status: Investigating
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 3.1 GA
    • Fix Version/s: 4.3 Backlog
    • Component/s: Web
    • Labels:
      None
    • Last commented by a User:
      true

      Description

      I was waiting the flash attributes feature in spring 3.1 but I was surprised that the attributes were stored in the HTTP session instead of cookie. My webapp is required to not have session because the infrastructure we use does not handle sticky session. I have done my own flash scope inspired from the one in playframework. It would be cool to be able to choose between http session or cookie.

        Issue Links

          Activity

          Hide
          trecloux Thomas Recloux added a comment -

          Hi Guys,
          One year later, I published a first version on the cookie based flash map manager.
          Encryption is now mandatory.

          To enable this component :

          • add dependency : (available in maven central)
            <dependency>
            <groupId>com.github.trecloux</groupId>
            <artifactId>spring-flash-cookie</artifactId>
            <version>0.2</version>
            </dependency>
          • Register the component in your spring configuration :
            <beans:bean id="flashMapManager" class="com.github.trecloux.flashcookie.CookieFlashMapManager">
            <beans:constructor-arg value="myPassword" />
            </beans:bean>

          Please give a try and send me your feedback

          Show
          trecloux Thomas Recloux added a comment - Hi Guys, One year later, I published a first version on the cookie based flash map manager. Encryption is now mandatory. To enable this component : add dependency : (available in maven central) <dependency> <groupId>com.github.trecloux</groupId> <artifactId>spring-flash-cookie</artifactId> <version>0.2</version> </dependency> Register the component in your spring configuration : <beans:bean id="flashMapManager" class="com.github.trecloux.flashcookie.CookieFlashMapManager"> <beans:constructor-arg value="myPassword" /> </beans:bean> Please give a try and send me your feedback
          Hide
          rstoya05-aop Rossen Stoyanchev added a comment -

          Thanks Thomas, I'll have a look! Just wondering if your intent is to submit a pull request or keep it as a separate project?

          Show
          rstoya05-aop Rossen Stoyanchev added a comment - Thanks Thomas, I'll have a look! Just wondering if your intent is to submit a pull request or keep it as a separate project?
          Hide
          trecloux Thomas Recloux added a comment -

          Hi Rossen, I'll be happy to submit a pull request if it can be integrated.

          Show
          trecloux Thomas Recloux added a comment - Hi Rossen, I'll be happy to submit a pull request if it can be integrated.
          Hide
          rstoya05-aop Rossen Stoyanchev added a comment -

          Thomas Recloux, I've had an initial look. Thanks for making that available!

          It's reasonably straight forward. A couple of things. Did you try serializing List<FlashMap> as-is rather than converting to a List<Map<String,Object>>?

          Also I see serialization and encryption as good targets points of variation – e.g. to use different libraries . One option is to introduce a base class with abstract methods for encoding/decoding. However since serialization and encryption may need to vary independently, perhaps a delegate strategy is better. For example FlashMapCodec with methods to go both ways List<FlashMap>-to-String. Then we would add a Jackson codec for serialization and a jasypt codec for encryption. Of course the encrypting codec would need to delegate to a serializing codec (Jackson) for the serialization part and provide encryption on top.

          What do you think?

          Show
          rstoya05-aop Rossen Stoyanchev added a comment - Thomas Recloux , I've had an initial look. Thanks for making that available! It's reasonably straight forward. A couple of things. Did you try serializing List<FlashMap> as-is rather than converting to a List<Map<String,Object>> ? Also I see serialization and encryption as good targets points of variation – e.g. to use different libraries . One option is to introduce a base class with abstract methods for encoding/decoding. However since serialization and encryption may need to vary independently, perhaps a delegate strategy is better. For example FlashMapCodec with methods to go both ways List<FlashMap>-to-String. Then we would add a Jackson codec for serialization and a jasypt codec for encryption. Of course the encrypting codec would need to delegate to a serializing codec (Jackson) for the serialization part and provide encryption on top. What do you think?
          Hide
          trecloux Thomas Recloux added a comment -

          Thanks for your feedback.

          When serializing List<FlashMap>, the specific attributes are not serialized, I think that jackson has special handling for Maps. I will have a deeper look.

          I agree with the delegate strategy for serialization / encryption.

          I started to move the code to a spring-framework fork.

          Show
          trecloux Thomas Recloux added a comment - Thanks for your feedback. When serializing List<FlashMap> , the specific attributes are not serialized, I think that jackson has special handling for Maps. I will have a deeper look. I agree with the delegate strategy for serialization / encryption. I started to move the code to a spring-framework fork.

            People

            • Assignee:
              rstoya05-aop Rossen Stoyanchev
              Reporter:
              ludovic.praud Ludovic Praud
              Last updater:
              Rossen Stoyanchev
            • Votes:
              4 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Days since last comment:
                1 year, 13 weeks, 2 days ago