Our existing JavaScript was listening for the submit event, but somehow things would still slip by periodically. I'm not sure how. It's a mystery.

Moving the logic server-side means that we no longer need to worry about the vast profusion of possible interactions of user agent, device, extensions, password managers and so on. There's exactly one computer that needs to get it right, and that's the EZ Proxy server.

Also, looking back at the first email in this thread, I see that I wrote about adjusting the email suffixes in the code snippet. That's actually not relevant. There was an earlier revision of the code where we explicitly listed the suffixes @und.edu and @ndus.edu as the ones to remove, and then realized we could just use a wildcard character instead. The code in the email got updated, but the actual email didn't. So the code is matching anything after an @ sign, and does not need to be adjusted for other domains. 

Will

-----Original Message-----
From: Code for Libraries <[log in to unmask]> On Behalf Of Eric Phetteplace
Sent: Monday, February 16, 2026 11:10 AM
To: [log in to unmask]
Subject: Re: [CODE4LIB] User name email suffix stripping

Just speculation, but the frontend JavaScript may be working less frequently as password managers and autofill are used more. It's possible some of those don't trigger the same events, like "blur", in an expected way. If you're listening to the "submit" event and then stripping the @domain.tld then this is less likely. Either way, making the fix on the backend seems the most foolproof.

Best,
Eric

On Mon, Feb 16, 2026 at 8:25 AM Hammer, Erich F <[log in to unmask]> wrote:

> Why not just have javascript code to watch for an "@" and throw up a 
> flag for the user and/or prevent submission?
>
>
> On Friday, February 13, 2026 at 15:22, Will Martin eloquently inscribed:
>
> > All,
> >
> > We've had a problem for years where people enter their email address 
> > as
> the
> > user name, which fails because our current configuration assumes 
> > they're entering just their user name. We've had a JavaScript 
> > attached to our
> login
> > pages for a long time which was designed to strip those suffixes 
> > off. But occasionally one would slip through anyway. I've never been 
> > clear on
> what set
> > of circumstances led the JavaScript to fail, but it's been happening 
> > more frequently of late.
> >
> > So over the past week we spent some time fiddling with user.txt and 
> > expressions, and came up with a server-side solution which appears 
> > to
> work.
> > Here is the code:
> >
> > ::Common
> > If login:user =~ [log in to unmask]*$/i {
> >   Set login:user   = REReplace([log in to unmask]*$/i, "", login:user)
> >   Set login:loguser = login:user
> > }
> > /Common
> >
> > This block of code goes immediate before the opening ::LDAP bit.  If 
> > you
> wish
> > to adjust this for use on your own servers, just swap out the email
> suffixes
> > that you want to strip off in that regular expression on lines 2 and 3.
> >
> > The advantage of doing it server side in user.txt is consistency. No
> worrying
> > about different browsers or the rare unicorn people who have 
> > JavaScript turned off or anything.
> >
> > We've had this going for a week at this point with no issues.
> >
> > Hope this helps someone.
> >
> > Will Martin (and also credit to Ethan Fria)
> >
> > Head of Digital Initiatives, Systems and Services Chester Fritz 
> > Library University of North Dakota
> >
> > He/his/him
> >
> > 701.777.4638
>