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=working/Evergreen.git;a=shortlog;h=refs/heads/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 |