Web Login and eaddress requirement

Hi,

Is it possible to create an account via the Web without an email address?  We want to allow people the chance to log into their existing account (with a login we created) and have them make changes to a subscription renewal without the need of an email address.  Anyone out there do something similar or is this not possible with how Tessitura is set up?

 

Thanks,

Tiffany :)

Database Coordinator

Huntington Theatre Company

Boston, MA

 

 

Parents
  • Hi, Tiffany:

     

    With v11 (which we are still using), you can still create a temp login that has nothing to do with an e-mail address in the account. It’s v12 that disallows this.

     

    We used temp logins, giving people enough information on their renewal forms to log in using them. They are prompted to create a permanent login once they use the temp login, however.

     

    Lucie

     

    ______________________________
    Lucie Spieler
    IT Development and Training Manager

    FLORIDA GRAND opera

  • Just so you all know, in v12, you are still able to create accounts without an email address with a specific password in a script. What is disallowed is retrieving that password since it is stored as a one-way hash.

    I'm not necessarily suggesting that is a good best practice; however, we had to do our latest subscription renewal process shortly after going live with v12 and discovered that with some coding changes, our current process of creating accounts for those who do not already have them and then printing username/password on their subscription renewal form still worked.

  • Thank you all. I feel a little bit better now. :)

    I'm going to take this inquiry a step further into the rabbit hole...

    It appears that our web environment is set up so that an email address is required on an account in order for the web login to be created.  In other words, the email address must be attached to an account in order for that person to be able to "lookup" their account and access it.

    We want to be able to give every subscriber access to a web account to see their renewals, regardless of if they have an email or not, so we have figured out a backdoor way of creating "fake" email addresses for the 300-400 subscribers who do not have emails.

    We do not distribute the fake emails to anyone.  They ONLY exists to allow a patron to use a temporary login/password, which we do send to them in the mail. Once the renewals are processed, the fake email address is deleted along with any login data. 

    It's kind of a backwards way of doing things and it's worked well pre v11, but I think there are some questions being raised about the security of this practice and how things tend to be changing with v12. 

    Has anyone done anything similar or figured out another way to giving all people access to the website without requiring a user provided email?  Also, if you are on v12, what are you sending out in your renewals if you cannot access the password?  Just a reminder of the login and instructions on how to re-set their password via the SendCredentials (which would require a valid email address)?

     

  • Hi Tiffany,

    We do a similar thing here at Sydney Symphony. We created a new type of login, which is just used for subs renewal time, and it's called "subs login". We did it in two steps:

    1) A script is run that creates an email address that is [customer_no]@sydneysymphony.com. No customer actually uses this email address, but it allows us to create a login.

    2) A second script creates a login that consists of the customer's customer_no as the login and their last name as the password.

     

    The idea behind this was to make it super-easy for them to login and renew, rather than having people create duplicate accounts and other sorts of silliness.

    Once we get v12, the problem will be that we will no longer be able to see their password, but as David said, you can still create the passwords. So technically speaking, we could create that username and password combo to provide to our subscribers and tell them that's what their login is, but we wouldn't be able to see it in the database back-end or in Tessitura.

     

    I'm in two minds about which way to go for this upcoming subs season. If we keep providing the simple subs login to people, it does certainly ensure that it's easy for people to renew online, but at the same time, we're kind of working around the idea of us not being able to see their password, which was the whole point of adding extra security in to v12 and hashing their password.

    But if we suddenly turn around and tell them they have to login with their email address, we now have to find a way of dealing with all the subscribers who don't have email addresses. We'd have to get a real email address off them, create accounts for them all. I suspect it will all become too complicated and we'll continue what we've always done in the past.

    So the short version is - yes, you can create a username and password, and tell them what it is, even despite the v12 changes, but it's not considered best practice.

  • Thanks for all your help everyone.

    :)

     

  • David,

    Can you explain your response to me?

    you are still able to create accounts without an email address with a specific password in a script

    Do you mean that you are able to create a login that is not an email address?  In what script? An SQL script?

     

    Thanks for any clarification.

     

    Adria Gunter-Studio Theatre, Washington, DC 

Reply Children
No Data