Uploaded image for project: 'OpenIDM'
  1. OpenIDM
  2. OPENIDM-12178

Progressive Profiling with Full Stack Broken

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 6.5.0
    • Fix Version/s: 6.5.0
    • Labels:
      None
    • Target Version/s:
    • Verified Version/s:
    • Story Points:
      3
    • Sprint:
      OpenIDM Sprint 6.5-10.2

      Description

      When using the full stack sample an IDM admin should be able to set up progressive profiling forms for user's to fill out upon logging on and upon completion they should be directed to their dashboard.

      Currently when an optional form is setup, the user is stuck in an infinite loop.

      Steps to reproduce:

      1. set up the full stack sample (can reproduce this without social authentication)
      2. set up an optional progressive profiling form. for example, i was using "address2 is not present" and the attribute to be filled out was "postal code" as non required.
      1. log in as an enduser
      2. user should be displayed Progressive profiling form that they should attempt to "skip"

       

      Current results:
      Attempting to skip results in a loop. the user is stuck on the progressive profiling form

       

      Expected results:
      user is allowed to skip an optional form

      Note:
      Investigation has already been done on this ticket by Jon Branch, Jason Browne, and Krismy Alfaro. The result of this investigation is that the jwt token that being produced was too large. The limit for a single domain is 4k for all cookies. 
      Since the token was too large, the session-jwt was not being updated and upon hitting the authentication?_action=login endpoint again, the jwt from the progressive profiling endpoint was not being persisted and caused a new session-jwt to be returned, which resulted in a loop.

      The reason this became an issue was because a few new fields were added to the jwt as part of this release which pushed us over the 4k limit. Upon inspecting the jwt contents, we found that the logoutUrl being persisted was 1k due to a token being present in it. 

      This logoutUrl is calculated as part of the amSessionCheck.js file and does not need to be persisted in the jwt. This allows us to have an extra 1k of space in the jwt. 

        Attachments

          Activity

            People

            • Assignee:
              brmiller Brendan Miller
              Reporter:
              krismy.alfaro Krismy Alfaro
              QA Assignee:
              Alexander Dracka
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: