spring-projects / spring-projects/spring-session

Provide the Session ID in requested session failure exceptions

Open
#3,436 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

status: waiting-for-triage type: enhancement
Dominant language
Java
Stars
1.9k
Forks
1.2k
Avg merge
4h 27m
Merged PRs (30d)
55

Description

Spring Session: 3.5.0

Expected Behavior

Right now SessionRepositoryFilter#getRequestedSession doesn't give us an easy way to know which session had a session deserialization issue as far as I can tell (please correct me if there's a better way to handle this, I haven't been able to find it as of yet) What would be helpful for our exception handling is if we caught the exception and loaded the exception with the session ID that had the issue.

I achieved this in my own SessionRepositoryFilter implementation (unfortunately the getRequestedSession is private for some reason so its messy to implement this as an extension to the SessionRepositoryFilter):

        private S getRequestedSession() {
            if (!this.requestedSessionCached) {
                List<String> sessionIds = httpSessionIdResolver.resolveSessionIds(this);
                for (String sessionId : sessionIds) {
                    if (this.requestedSessionId == null) {
                        this.requestedSessionId = sessionId;
                    }
                    // HACK: Make sure we can get access to the session ID
                    try {
                        S session = sessionRepository.findById(sessionId);
                        if (session != null) {
                            this.requestedSession = session;
                            this.requestedSessionId = sessionId;
                            break;
                        }
                    } catch (SerializationException | SerializationFailedException se) {
                        handleException(new SessionSerializationException("Problem serializing session", sessionId, se));
                    } catch (Exception ex) {
                        handleException(new SessionSerializationException("Problem finding session", sessionId, ex));
                    }
                }
                this.requestedSessionCached = true;
            }
            return this.requestedSession;
        }

Current Behavior

Currently its like so and will just throw the exception with no context of the session:

        private S getRequestedSession() {
            if (!this.requestedSessionCached) {
                List<String> sessionIds = httpSessionIdResolver.resolveSessionIds(this);
                for (String sessionId : sessionIds) {
                    if (this.requestedSessionId == null) {
                        this.requestedSessionId = sessionId;
                    }
                    S session = sessionRepository.findById(sessionId);
                    if (session != null) {
                        this.requestedSession = session;
                        this.requestedSessionId = sessionId;
                        break;
                    }
                }
                this.requestedSessionCached = true;
            }
            return this.requestedSession;
        }

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in SessionRepositoryFilter#getRequestedSession and trace how sessionRepository.findById failures are handled. Confirm how the requested session ID is available when deserialization or lookup fails, then ensure the resulting exception includes that ID. Done means session failure exceptions provide the session ID as context without changing successful session lookup behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
backend
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.