Web User Account Changes

Hello all,

Has anyone else ever had an issue in which their Web User account information is somehow changed online by a patron?  We have had this issue 3 times in the last 2 years and when it occurs our website shuts down.

Just looking for anyone who may have run into this and any info you may have about what might be happening or why.

Thanks,

Angela Leftwich

Tennessee Performing Arts Center

Parents
  • Hi Angela,

     

    I’ve run into this a few times at my last organization…  I don’t remember exactly what was wrong on the technical side (something to do with session keys and the transfer process from anonymous account to a logged-in account not happening properly). As soon as we changed the password on the web account back to what it should have been everything started working again.   At the end of the day, the best resolution we could come up with was the idea to write some web code that would prevent anyone from changing the anonymous web user info. 

     

    Cheers,

    Kathleen

     

    From: Tessitura Web Forum [mailto:forums-tessitura-web@tessituranetwork.com] On Behalf Of Angela Leftwich
    Sent: Wednesday, August 13, 2014 2:16 PM
    To: Kathleen Smith
    Subject: [Tessitura Web Forum] Web User Account Changes

     

    Hello all,

    Has anyone else ever had an issue in which their Web User account information is somehow changed online by a patron?  We have had this issue 3 times in the last 2 years and when it occurs our website shuts down.

    Just looking for anyone who may have run into this and any info you may have about what might be happening or why.

    Thanks,

    Angela Leftwich

    Tennessee Performing Arts Center




    You were sent this email automatically because you subscribed to the Tessitura Web forum. You may reply to this message to post to the Web forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!

  • This happened when we first launched our website 3 years ago and like Kathleen I believe it has to do with transferring from the anonymous account to a logged in account.  I also think this may be more likely to happen in a load balanced environment or when there is higher traffic. We added code to check for the anonymous account trying to update any account information and prevent it. We identify the anonymous account by ID.

  • Former Member
    Former Member $organization in reply to David Meyer

    We've had the same problem here.  Our site was originally coded such that the responsibility for handling Tessitura sessions and authentication was strewn haphazardly across multiple layers of the application, resulting in unpredictable edge cases.  The problem is likely that one part of your site thinks the session is authenticated as a specific constituent, but by poor distribution of responsibilities, that authentication has been lost or changed behind its back.

    You should inspect your code wherever it creates a new session or modifies the authentication of the session.  This would be wherever it directly or indirectly calls:

    • GetNewSessionKey
    • GetNewSessionKeyEx
    • Register
    • RegisterWithPromoCode
    • RegisterWithPromoCodeEx
    • Login
    • LoginEx
    • LoginEx2
    • LoginEx3
    • LoginWithPromoCode
    • UpdateLogin
    • UpdateLoginWithPromoCode
    • TransferSession

    Also, make sure that registration and login pages are inaccessible to authenticated users, because certain registration / login failures can unexpectedly deauthenticate the session.  If the session gets unexpectedly deauthenticated, another part of your site may automatically reauthenticate as the anonymous consistuent.

    Finally, the UpdateLogin methods can also fail in a manner that deauthenticates the session.  So when a user attempts to change their password, and they enter a wrong old password, not only does their password fail to change, but the session loses authentication.  (I seem to remember this happening from three years ago.)

Reply
  • Former Member
    Former Member $organization in reply to David Meyer

    We've had the same problem here.  Our site was originally coded such that the responsibility for handling Tessitura sessions and authentication was strewn haphazardly across multiple layers of the application, resulting in unpredictable edge cases.  The problem is likely that one part of your site thinks the session is authenticated as a specific constituent, but by poor distribution of responsibilities, that authentication has been lost or changed behind its back.

    You should inspect your code wherever it creates a new session or modifies the authentication of the session.  This would be wherever it directly or indirectly calls:

    • GetNewSessionKey
    • GetNewSessionKeyEx
    • Register
    • RegisterWithPromoCode
    • RegisterWithPromoCodeEx
    • Login
    • LoginEx
    • LoginEx2
    • LoginEx3
    • LoginWithPromoCode
    • UpdateLogin
    • UpdateLoginWithPromoCode
    • TransferSession

    Also, make sure that registration and login pages are inaccessible to authenticated users, because certain registration / login failures can unexpectedly deauthenticate the session.  If the session gets unexpectedly deauthenticated, another part of your site may automatically reauthenticate as the anonymous consistuent.

    Finally, the UpdateLogin methods can also fail in a manner that deauthenticates the session.  So when a user attempts to change their password, and they enter a wrong old password, not only does their password fail to change, but the session loses authentication.  (I seem to remember this happening from three years ago.)

Children
No Data