Shared Session Authentication Question

Hello! I am reaching out to this community, as we are currently down an internal web person, and I am hoping you might be able to provide insight into an issue we are having with our outside developer. 

Most of our members want to be able to purchase multiple tickets in one session. However, currently, if you go back and forth between TNEW and our html site, the cart empties.

I received the below response from our developers. They are new to Tessitura, and I am just having a hard time believing that the shared session functionality doesn't provide a way around this:

"After looking into this further, our developers determined that there is no resolution for this workflow. Every time we hand-off to TNEW, we wipe the existing TNEW cart and populate TNEW with the cart from fords.org.

The reason for this is twofold:

  • We can't properly detect through unique IDs what no longer exists in the org cart vs the TNEW cart. If you added three seats to general admission, go to TNEW but return to our cart, and then hand-off to TNEW again, you end up with 6 general admissions tickets.
  • We don't actually store the SYOS entry in the fords.org cart because SYOS tickets are added directly in TNEW and TNEW doesn't hand that information back to the fords.org through a hook. We have no knowledge on the fords.org site's end on whether you actually chose a seat."

Is their assessment correct or are they missing something? Thanks for your help!

Liza Lorenz

Director of Communications

Ford's Theatre

 

  • I don't have direct experience with the Shared Session authentication feature, but I do have a lot of familiarity with TNEW precart and validation point customizations. It sounds like your developers are trying to follow a model usually used where the ENTIRE order creation process is done on your custom site, and then only for the last step do you hand the cart off to TNEW so they can securely process the payment. (A number of these were shown off in one of the TLCC general sessions last year, or maybe the year before.) In this kind of model, it is fine for the cart state to be maintained by the custom site application up until it is time for handoff. If I understand correctly, this model is proving not to be the correct design for your site, if you want the customer to seamlessly be able to bring their cart back and forth between TNEW and your custom site.

    TNEW itself does not store cart state in an inaccessible manner; all cart state is stored right in the database as the user goes through their purchase path. You can add and remove items from the cart with API calls, and TNEW will pick these up on its next page load. You can of course also retrieve the current cart from the API as well. All of this information is identified by the session key that you should be sharing between TNEW and your custom site.

    So it sounds like instead of building your cart state privately in your custom site before handing it off to TNEW in a one-way gesture, you need to be maintaining cart state in the same way that TNEW does, by persisting it in the database via API methods. Then you are literally sharing the session between TNEW and your custom site.