Evergreen ILS Website

IRC log for #evergreen, 2022-12-16

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
07:09 kworstell-isl joined #evergreen
07:57 BDorsey joined #evergreen
08:01 mantis1 joined #evergreen
08:23 stompro__ joined #evergreen
08:35 rfrasur joined #evergreen
08:37 mmorgan joined #evergreen
08:50 Dyrcona joined #evergreen
09:30 Bmagic @coffee scottangel
09:31 * pinesol brews and pours a cup of Kenya Peaberry Muthunzunni Estate, and sends it sliding down the bar to scottangel
09:31 Bmagic @coffee [someone]
09:31 * pinesol brews and pours a cup of Bonsai Blend Espresso, and sends it sliding down the bar to ejk
09:31 Dyrcona We use a custom schema for local functions, views, and tables. I've also been using it for storing data before temporary updates so that the values can be restored later, like when a library asks to change the status or location on copies when they're temporarily closed, etc.
09:31 Bmagic @coffee [someone]
09:31 * pinesol brews and pours a cup of Kenya Giakanja, and sends it sliding down the bar to Dyrcona
09:31 scottangel Bmagic is our Evergreen barista! thank you kind sir!
09:31 scottangel Bmagic++
09:31 Bmagic :)
09:32 Bmagic scottangel++
09:32 Dyrcona I'm considering moving those "temporary" tables to a different schema, possibly cwtemp or localtemp. I was just wondering if anyone else does something like that or has thoughts on it.
09:33 Dyrcona FYI, Bmagic: I'm about ready to upgrade Evergreen on our dev server using this branch or a derivative: https://git.evergreen-ils.org/?p=worki​ng/Evergreen.git;a=shortlog;h=refs/hea​ds/user/dyrcona/cwmars_custom_rel_3_10
09:34 * Dyrcona probably needs something stronger than Glakanja this morning... :)
09:35 Bmagic You go on with your bad self!
09:36 Dyrcona Bmagic: I've updated the apps_dev repo as well.
09:37 kworstell_isl joined #evergreen
09:38 kworstell_isl_ joined #evergreen
09:55 mmorgan Dyrcona: We have a local schema. We also use the existing staging schema for temporary tables.
09:59 Dyrcona mmorgan: That's interesting. I'm not really fond of using the staging schema. We use it for our patron loads and that's it. I made a new schema for our backstage process.
10:00 kworstell-isl joined #evergreen
10:03 RMillerOCS joined #evergreen
10:16 Dyrcona We have 3 local schemas, what's one more at this point? :)
10:18 RMillerOCS Working on the fresh install of OpenSRF and now Evergreen. Any idea why the eg_db_config script is giving me the error "Cannot create database; version of PostgreSQL appears to be less than the minimum required of 9.6"? (It's 14.)
10:19 RMillerOCS I backed up the old evergreen database and then dropped it
10:19 kworstell_isl joined #evergreen
10:19 sleary joined #evergreen
10:25 RMillerOCS nm I think I got it- old config files were hanging around. Now I have a different set of problems to tackle :)
10:25 Christineb joined #evergreen
10:42 jvwoolf joined #evergreen
10:56 kworstell-isl joined #evergreen
11:12 * Dyrcona decides to hold off on creating yet another schema.
11:52 mmorgan @decide YAS or YAOUS
11:52 pinesol mmorgan: That's a tough one...
11:52 mmorgan :)
12:13 jihpringle joined #evergreen
13:12 Stompro_home Has anyone dealt with a sip2 using vendor needing case insensitive passwords (uppercased)?
13:14 Stompro_home I'm thinking that Evergreen would need to store two hashes for each user, and the auth function would need a way to either specify the uppercase hash, or detect it based on the password?
13:15 Stompro_home And then all users would need to log in once, to populate the extra hash.
13:16 Dyrcona I've never heard of case insensitive passwords. In fact, that's a very bad idea.
13:16 Dyrcona Tell them that they are wrong. You will not compromise your security in that way.
13:18 Stompro_home I think it must be something that was previously common, our Cassie patron management SIP setup has a flag for it, to always send passwords uppercased.
13:19 Dyrcona NO! That should absolutely not have ever been common. Except only in the '60s when some system could only do uppercase, but then most systems didn't have passwords, either.
13:20 Stompro_home I may be mistaken with a similar setting for the barcode... let me check.
13:24 Stompro_home Nope, there is a setting "Send standard user Passwords/PINs as case sensitive"  implying that without it set, Passwords/PINS are not case sensitive.
13:24 Stompro_home There is note "As of this writing, the only systems that we are aware of that require this are the
13:24 Stompro_home Evergreen/Koha ILS SIP Server and the Polaris ILS SIP Server. Other ILS authentication
13:24 Stompro_home servers perform case insensitive password/PIN comparisons to make the systems more
13:24 Stompro_home forgiving for patrons and less staff intensive with password reset/lookup requests. If you are
13:24 Stompro_home unsure, leave this option unchecked."
13:25 * jeffdavis weeps
13:25 Dyrcona Ha! I don't believe that comment for half a second, 'cause I'm 99% sure that passwords are case sensitive in Horizon.
13:26 Dyrcona IDGAF what the rest of the idiots in Library Land do. It's nearly 2023. This is a hill. It's worth dying on it.
13:26 jeffdavis This is in Cassie? We have a few libraries using that but I don't think this "feature" has come up.
13:26 Stompro_home I have millennium experience, but all those memories have greatly faded, so I don't remember it at all.
13:27 Stompro_home jeffdavis, yes, that is a Cassie setting.  But my issue isn't with Cassie, that was just an example of the possibility of case insensitive passwords being a thing.
13:28 Dyrcona Ranting aside. I will not accept such a patch. If I find such a patch in Evergreen. I will revert it. If someone puts it back, I will revert it again. If someone keeps putting it back, I will yank their commit access unless I'm voted off the island.
13:29 Dyrcona That sounded like a rant, didn't it. ;)
13:29 Stompro_home Dyrcona, I understand your position, I don't want it to be a thing either.
13:30 Dyrcona Do you actually have to deal this or is this a hypothetical?
13:31 Stompro_home Our legacy state wide resource sharing system has that requirement currently, and they would like everyone to enable PINS asap.  Currently we don't require PINS for that service.
13:34 Dyrcona Well, users can have different passwords for different access mechanisms. At least the plumbing is there.
13:34 Stompro_home The system is on life support, they are going through RFPs for a new system.  OCLC maintains the current system, but not with much resources.  So I don't know if they can get anything having to do with the authentication modified.
13:37 jeffdavis I haven't run into a system that required case-insensitive passwords before. I'm not really surprised some systems work that way but I wouldn't say it's common. Not requiring a password/PIN at all is more common, in my experience.
13:37 Stompro_home Dyrcona, I didn't know that, thanks.  Hopefully they will be able to just remove that requirement for the automation systems that need it removed.
13:39 Dyrcona I was about to add that you could setup a SIP passwd_type and possibly teach the SIP code to use it. This would mean different passwords for each user who uses SIP, and it would not be possible to determine a user's current password to populate them with all-uppercase versions.
13:40 Dyrcona I suppose 4-digit PINs could be added in a similar way, but I am not a fan of doing either, really.
13:40 Dyrcona I'm also not a fan of users giving their passwords to 3rd party services, so probably setting a special SIP password is the better idea after all.
13:42 Stompro_home That is another aspect of it, a large majority of our uses use 4 digit pins for their passwords, so this work is just for the percentage that actually changes their password after getting a card.
13:42 Dyrcona I'm not sure how you would enable case insensitivity in password on the Evergreen side, though, no how you'd get patrons to set up the SIP passwords to begin with.
13:43 Dyrcona I think that "no" should have been "or."
13:44 Dyrcona PINs are really only useful with a physical access token, and even then they are not great.
13:45 Dyrcona Security is hard....What good's a dead bolt when the door is made of cardboard? ;)
13:47 * Dyrcona grumbles about why we're not using PKI already.....
13:48 Stompro_home Dyrcona, thank you for sharing your thoughts with me.
13:49 Dyrcona Sorry for ranting a bit. Access is mostly a solved problem. It's just nobody likes the solutions because they're inconvenient.
14:02 * Dyrcona should find out what's the latest-greatest for authenticating users via another site, like signing in with your Facebook or Google account. Last time I looked it was OAuth2. We could add some thing like that to Evergreen that works both ways. Thought Evergreen authenticating agains something else has issues because Evergreen users can share email addresses, etc.
14:05 stompro__ joined #evergreen
14:13 Stompro_home Dyrcona, OAuth2 would be neat, that would take care of sharing passwords with vendors I believe.  I wonder if it would also allow overdrive accounts to not be based on barcodes, so account merging isn't necessary anytime a customer gets a new barcode.
14:13 jihpringle joined #evergreen
14:20 jihpringle joined #evergreen
14:23 Dyrcona The trick would be getting vendors to use OAuth2.
14:31 mmorgan1 joined #evergreen
14:51 mmorgan joined #evergreen
15:10 Dyrcona If there's no web/eg2, that means I forgot to do ng build, right?
15:11 Dyrcona Looking at /openils/var/web/eg2/en-US/ and the timestamps on the files in there, I would say, "Yes."
15:12 * mmorgan would agree :)
15:18 Dyrcona :)
15:52 jvwoolf left #evergreen
17:08 mmorgan left #evergreen
21:48 Stompro_home joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat