| Time |
Nick |
Message |
| 02:26 |
|
berick_ joined #evergreen |
| 07:14 |
|
jboyer-isl joined #evergreen |
| 07:42 |
|
rjackson-isl joined #evergreen |
| 07:48 |
|
collum joined #evergreen |
| 08:05 |
|
mrpeters joined #evergreen |
| 08:22 |
|
_bott_1 joined #evergreen |
| 08:36 |
|
kmlussier joined #evergreen |
| 08:36 |
|
kbeswick joined #evergreen |
| 08:40 |
csharp |
@quote random |
| 08:40 |
pinesol_green |
csharp: Quote #66: "<csharp> EVERYBODY KEEP SAYIN' FUNNY STUFF!" (added by gmcharlt at 02:29 PM, August 13, 2013) |
| 08:43 |
|
Shae joined #evergreen |
| 08:43 |
|
misilot joined #evergreen |
| 08:46 |
|
misilot left #evergreen |
| 08:47 |
|
akilsdonk joined #evergreen |
| 08:54 |
|
timf joined #evergreen |
| 09:08 |
|
mmorgan joined #evergreen |
| 09:13 |
|
Dyrcona joined #evergreen |
| 09:29 |
|
Dyrcona joined #evergreen |
| 09:32 |
|
jeff joined #evergreen |
| 09:39 |
|
ericar joined #evergreen |
| 09:54 |
pinesol_green |
[evergreen|Elliot Voris] Documentation typo in Authorities chapter subheading - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b6833de> |
| 10:00 |
|
yboston joined #evergreen |
| 10:01 |
|
jasonb-iph joined #evergreen |
| 10:02 |
|
BigRig joined #evergreen |
| 10:04 |
|
phasefx2 joined #evergreen |
| 10:05 |
|
tater joined #evergreen |
| 10:05 |
|
senator joined #evergreen |
| 10:07 |
|
ningalls joined #evergreen |
| 10:07 |
|
eeevil joined #evergreen |
| 10:07 |
|
gdunbar joined #evergreen |
| 10:07 |
|
jcamins joined #evergreen |
| 10:08 |
|
rangi joined #evergreen |
| 10:08 |
|
rangi joined #evergreen |
| 10:18 |
Dyrcona |
3rd_party_vendors-- |
| 10:18 |
bshum |
Agreed. |
| 10:18 |
Dyrcona |
sip2-- |
| 10:20 |
berick |
Dyrcona: what specifically do you dislike about the proposal? |
| 10:20 |
jeff |
? |
| 10:20 |
* jeff |
looks for context |
| 10:20 |
berick |
apart from sip is dumb |
| 10:21 |
berick |
https://bugs.launchpad.net/evergreen/+bug/1259196 |
| 10:21 |
bshum |
jeff: bug 1259196 |
| 10:21 |
pinesol_green |
Launchpad bug 1259196 in Evergreen "SIP support workstation option at login" (affected: 1, heat: 6) [Wishlist,New] |
| 10:21 |
Dyrcona |
It would mean a proliferation of sip2 accounts in the database and in oils_sip.xml. |
| 10:21 |
berick |
ah, gotcha |
| 10:21 |
Dyrcona |
If library X has 5 selfchecks, that means 5 sip2 accounts. |
| 10:21 |
bshum |
That makes me queasy. |
| 10:22 |
Dyrcona |
Like I said in the bug, I can't think of any other way to do what you propose. |
| 10:22 |
berick |
right |
| 10:22 |
Dyrcona |
As if 3M would implement an extension field for storing a workstation identifier. |
| 10:22 |
berick |
even if we offer an extension, getting.. |
| 10:22 |
berick |
exactly |
| 10:24 |
Dyrcona |
As long as the field is ignored if not present, i.e. doesn't throw an error, I'm OK with it. |
| 10:26 |
Dyrcona |
I added those remarks to the bug, so its all in one place. |
| 10:26 |
tsbere |
I wouldn't object to something like "workstation by what IP you connected from" in the config file, except for the fact that it would be useless for MVLC. |
| 10:28 |
eeevil |
Dyrcona: there's a good reason to /require/ separate logins for each device, though ... password lockout :) |
| 10:28 |
jeff |
we use one sip account per sip client. |
| 10:29 |
jeff |
also, there is a SIP field that is designed for this purpose, but last i looked (last week) there was at least one challenge with using it that way in current SIPServer |
| 10:30 |
jeff |
while we're at it, i'm still interested in the sip config file having the ILS credentials, but also having a hashed/salted password that the SIP client uses, which is distinct -- so that the sip client does not contain ILS credentials. :-) |
| 10:30 |
jeff |
that might be unpopular, or popular. i dunno. |
| 10:30 |
Dyrcona |
eeevil: It's not me that really has the problem with it. I think a number of my members would get mad at having multiple logins. |
| 10:31 |
jeff |
i'm not sure how we'd have survived without one user per sip client. |
| 10:31 |
* jeff |
looks at the bug |
| 10:31 |
Dyrcona |
jeff: It depends on your needs, I guess. |
| 10:32 |
Dyrcona |
Although, I'm not fond of the management overhead added by having multiple self check logins for 36 member libraries. |
| 10:33 |
eeevil |
jeff: an optional client-side-only authen layer (triggered by the presence of an attr containing a 41 char string (sha1 hash)) seems reasonably simple, actually |
| 10:33 |
* Dyrcona |
is not a fan of passwords, either. Can we all just use client certificates already? |
| 10:34 |
jeff |
eeevil: i was thinking more along the lines of "if clientpassword attribute is present, check the incoming password from the SIP client against that (hashed + salted) value, and use the value of the password attribute to auth to the ILS" |
| 10:35 |
eeevil |
jeff: right, exactly |
| 10:35 |
jeff |
that way, no changes required at upgrade unless and until you want to take advantage of the new option. |
| 10:36 |
jeff |
and you could use it for some users but not others, either due to policy/desire or due to staged rollout of the new credentials to clients. |
| 10:37 |
Dyrcona |
Why hash and salt something that is sent in the clear anyway? |
| 10:38 |
Dyrcona |
The '80s called. They want telnet and ftp back. |
| 10:38 |
dbs |
tunnels, tunnels everywhere |
| 10:39 |
jeff |
tunnelling sip over ssl or ssh is highly recommended by 100% of jeffs making this statement. |
| 10:42 |
Dyrcona |
We tunnel over ssh. I am curious what you think you gain by hashing and salting passwords in oils_sip.xml. |
| 10:43 |
Dyrcona |
If someone has access to the server and can read that file, and intends to do something malicious, you've got bigger problems. |
| 10:43 |
jeff |
but to answer your question about "why hash+salt", "because the sip server doesn't need to cleartext sip client password -- just the cleartext ILS password" |
| 10:43 |
jeff |
Dyrcona: is /etc/shadow world readable on your systems? are the passwords within hashed and salted? |
| 10:44 |
jeff |
(and of course oils_sip.xml is not /etc/shadow, and /etc/shadow does not contain any cleartext credentials to auth to another system...") -- i didn't claim it was a perfect example. :-) |
| 10:44 |
Dyrcona |
jeff: That's different. How many users on your Evergreen system? /etc/shadow is a generic solution to a generic problem. If you run Evergreen on a truly multi-user GNU/Liinux system, then your performance likely sucks. |
| 10:46 |
jeff |
but the basic idea is there -- if someone unauthorized can read /etc/shadow, you have big problems. still not a bad idea to have the contents hashed and salted. |
| 10:47 |
Dyrcona |
Right, but if an unauthorized person can read oils_sip.xml, they can read opensrf.xml and opensrf_core.xml and you've got bigger problems than them getting a client's sip credentials. |
| 10:47 |
Dyrcona |
Better to secure your server. |
| 10:47 |
Dyrcona |
Better to come up with an alternative to SIP that is encrypted. |
| 10:49 |
jeff |
given some event that results in the disclosure of your SIP config file, having the client passwords hashed ahd salted can help (say, you might not need to change a dozen sip client passwords until your next maintenance window) |
| 10:49 |
jeff |
but mostly, back to my original: "because the sip server doesn't need the cleartext sip client password" |
| 10:50 |
Dyrcona |
I don't find either argument compelling enough, and I have slipped a few passwords by accident in the past and had to change them. |
| 10:50 |
* csharp |
reads scrollback... |
| 10:52 |
csharp |
we have many many SIP logins since we started suggesting/sorta-requiring one login per device |
| 10:52 |
csharp |
it is a lot of overhead |
| 10:52 |
* csharp |
is actually considering setting up some sort of conf.d type approach with a dir per library |
| 10:53 |
Dyrcona |
csharp++ # conf.d would actually be useful to help manage a lot of credentials. |
| 10:54 |
jeff |
with support for a new client SIP password distinct from the ILS password, the ILS password would only be used by SIPServer and the ILS -- which opens the possibility of having an automated establishment of those credentials, or even a script to rotate them. :-) |
| 10:56 |
|
gsams joined #evergreen |
| 10:56 |
dbs |
SIP clients should use two-factor authentication. "Go get your phone, client!" |
| 10:56 |
Dyrcona |
Oh. Right. You're expecting blue-haired grannies to manage passwords, now..... |
| 10:56 |
Dyrcona |
dbs++ |
| 10:56 |
jeff |
Dyrcona: who is? |
| 10:56 |
Dyrcona |
You are. |
| 10:56 |
jeff |
Dyrcona: sorry, i must have been unclear. |
| 10:57 |
Dyrcona |
Two factor authentication: Based on something you can forget and something you can lose. |
| 10:58 |
* csharp |
agrees in theory with Dyrcona's keys approach |
| 10:58 |
Dyrcona |
My point is if you're trying to improve the security of SIP, then encrypt the connections everywhere by default. |
| 10:58 |
Dyrcona |
Rather than salt and hash client credentials, why not just remove them? |
| 10:58 |
jeff |
Dyrcona: i'm suggesting that we recommend one optional thing (one user per SIP client) and support one optional feature (the ability for the sip client password to be distinct from the ILS password). not sure where this is expecting anyone that isn't currently in the business of managing passwords to manage them new. |
| 10:59 |
Dyrcona |
I'm not arguing with the one user per SIP client. |
| 10:59 |
jeff |
cool. |
| 10:59 |
|
akilsdonk_ joined #evergreen |
| 10:59 |
jeff |
not sure where i'm being unclear. |
| 10:59 |
Dyrcona |
I don't use that configuration, but I see why you'd want it. |
| 10:59 |
jeff |
perhaps code and docs in a new wishlist ticket or two would be the best way to express myself. |
| 11:00 |
Dyrcona |
I get what you're saying now, but I still don't see what salt+hash really gains you in an Evergreen environment. |
| 11:01 |
Dyrcona |
You've separated sip credentials from database login. That gets you something. Someone can't use a sip account to login otherwise. |
| 11:01 |
* csharp |
sees a security/CYA advantage to salt+hash, if not a technical one |
| 11:01 |
Dyrcona |
Sure, but see my remark above about exposure of the /openils/conf directory. |
| 11:02 |
jeff |
i see it as practicing good security hygiene. |
| 11:02 |
Dyrcona |
I see it as washing one armpit and not washing the other. |
| 11:02 |
Dyrcona |
You don't do security piecemeal. That's why most security actually sucks. |
| 11:03 |
jeff |
i am not advocating a piecemeal approach. |
| 11:03 |
jeff |
i am advocating that the approach be able to interoperate with existing SIP clients. |
| 11:04 |
Dyrcona |
The existing SIP clients and the SIP protocol are the problem. |
| 11:04 |
Dyrcona |
Not how your store credentials on a server. |
| 11:06 |
csharp |
I'm interested in SSL/SSH approaches to SIP clients, but my stomach starts to hurt when I think about implementation in PINES |
| 11:06 |
jeff |
Dyrcona, csharp: who performs the SIP client configuration in the field in your respective environments? |
| 11:06 |
csharp |
jeff: each library handles that individual |
| 11:06 |
csharp |
ly |
| 11:06 |
jeff |
csharp, Dyrcona: how (if at all) is SIP traffic secured on the wire in your environments? |
| 11:07 |
Dyrcona |
ditto. we give them a CD or a download so they can set up a ssh tunnel with putty. |
| 11:07 |
csharp |
we're currently using telnet |
| 11:07 |
csharp |
so *none* |
| 11:07 |
jeff |
non-public network, ssh or ssl from a gateway host, ssh or ssl from the SIP client itself? |
| 11:08 |
Dyrcona |
our outside vendors come in clear text over the wire, but the unencrypted sip port (ie. not using the tunnel) is blocked by default in our firewall with specific IPs allowed access. |
| 11:08 |
jeff |
Dyrcona: you give them what they need to create an ssh tunnel -- do they run this on the sip client, or on a staff workstation, or something else? |
| 11:09 |
Dyrcona |
jeff: Like I said we give them what they need. We'll even set it up. We have them run it on another workstation or server in the library depending on their setup. |
| 11:09 |
jeff |
feel free to answer in msg or not at all, but what external SIP clients (SIP clients not running on a device located at one of your libraries) do you have? |
| 11:09 |
Dyrcona |
jeff: I think you'd better spend your time developing a replacement for SIP and NCIP while you're at it. |
| 11:11 |
Dyrcona |
jeff: The usual suspects. :) |
| 11:25 |
jeff |
Dyrcona++ |
| 11:25 |
jeff |
csharp++ |
| 11:39 |
bshum |
tsbere++ # fix for bug 1259231 |
| 11:39 |
pinesol_green |
Launchpad bug 1259231 in Evergreen "No email address message stuck in staff client" (affected: 1, heat: 6) [Medium,Confirmed] https://launchpad.net/bugs/1259231 |
| 11:44 |
mmorgan |
I'm looking for a way to send email notification to a group of patrons (read students) that have anything checked out. Anyone doing this? |
| 11:44 |
pinesol_green |
[evergreen|Thomas Berezansky] Always show Email Address label to staff - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5668f8d> |
| 11:44 |
bshum |
mmorgan: I've often wished for an "on-demand" email notifier for situations like that. |
| 11:45 |
bshum |
As is, I think some folks are managing by using reports and mail merge or such |
| 11:45 |
jeff |
mmorgan: we use the same service we use for our email newsletters, fed by an on-demand report -- it's infrequent enough that it's very manual at present. |
| 11:45 |
mmorgan |
I'll happily open a launchpad bug, but didn't want to if I'm missing something obvious. |
| 11:46 |
jeff |
i am working currently to sync patron email addresses automatically, including some basic information about account type / residency qualifications, but not currently anything as frequently-changing as "has something checked out right now" |
| 11:46 |
jeff |
mmorgan: what's your use case? |
| 11:47 |
mmorgan |
Our academics want to send statements at the end of each term to their students who still have things checked out before they leave for the semester. |
| 11:47 |
bshum |
Ours is something like an end of semester notification. The year is ending soon, please return your books. |
| 11:47 |
bshum |
Same as mmorgan's scenario apparently :) |
| 11:47 |
tsbere |
mmorgan: Beyond the having things checked out aspect I came up with ways to send emails via Evergreen....but I am not sure I want to document them even in IRC. |
| 11:48 |
mmorgan |
Once they leave after finals chances that the outstanding items go down dramatically. |
| 11:48 |
mmorgan |
insert " come back" in there somewhere :) |
| 11:51 |
mmorgan |
was looking for some way to do it with a trigger, but don't see one. |
| 11:54 |
|
gdunbar joined #evergreen |
| 11:56 |
|
jcamins joined #evergreen |
| 11:57 |
kmlussier |
I haven't gotten around to scheduling a dev meeting yet, but I was wondering if there is any inclination to skip a December dev meeting. Given that it's a busy time of year and all that good stuff. |
| 11:58 |
|
fparks joined #evergreen |
| 11:58 |
|
sseng joined #evergreen |
| 11:58 |
|
ktomita joined #evergreen |
| 11:58 |
|
smyers_ joined #evergreen |
| 12:01 |
bshum |
I would be +1 to waiting for January for the next dev meeting. |
| 12:01 |
bshum |
I was also going to suggest that since we held off on the point releases last month, that maybe we can put them to January for those too. |
| 12:02 |
bshum |
To give us some more time to find bugs, fix them, and merge them |
| 12:02 |
bshum |
(or something like that) |
| 12:05 |
|
akilsdonk joined #evergreen |
| 12:10 |
|
akilsdonk joined #evergreen |
| 12:12 |
|
sseng joined #evergreen |
| 12:22 |
* Dyrcona |
agrees with bshum. |
| 12:23 |
bshum |
Conversely, I see this as an opportunity to hold our first bug day. December 25 work for everyone? :P |
| 12:26 |
jeff |
:P |
| 12:28 |
|
cs5120288_ joined #evergreen |
| 12:32 |
Dyrcona |
jeff: tsbere is having a phone conversation right now that would be more difficult to resolve if sip client passwords were salted and hashed in oils_sip.xml. |
| 12:32 |
jeff |
oh? howso? |
| 12:33 |
Dyrcona |
One of our sites has entered an incorrect password in their client. He can tell them what the password should be by looking at oils_sip.xml. |
| 12:33 |
tsbere |
In this case it is more of a "if we properly sanitized the LOGS to remove passwords" >_> |
| 12:34 |
Dyrcona |
We could (and actually do) store a lit of passwords elsewhere, but that also defeats the purpose of hashing them. |
| 12:35 |
Dyrcona |
s/lit/list/ |
| 12:35 |
jeff |
i appreciate the example. :-) |
| 12:36 |
Dyrcona |
From his last comment, it sounds like he only used the logs. I guess they were setting up a new client and he could see prior successful logins. |
| 12:37 |
Dyrcona |
bshum: I've got plan on the 25th. What about the 1st of January? |
| 12:38 |
bshum |
Dyrcona: New year's resolution, fix all the bugs |
| 12:38 |
bshum |
I like it. |
| 12:38 |
tsbere |
I used our non-config file list of passwords + logs that showed the wrong password. <_< |
| 12:38 |
Dyrcona |
bshum: Good luck with that. :) |
| 12:39 |
Dyrcona |
tsbere: That's good. Undermine your boss' argument in public. :p |
| 12:42 |
jeff |
SIPServer needs a service-impacting restart to re-read its config at present, right? |
| 12:43 |
Dyrcona |
jeff: yes, it does. |
| 12:43 |
jeff |
that would be another something I'd like to see change. teach it to re-read at least credentials on HUP or similar. |
| 12:44 |
Dyrcona |
jeff: that would be good, like an apache reload. |
| 12:45 |
Dyrcona |
jeff: You also reminded me that I'd like to make the --localhost argument to osrf_control unnecessary. I think I'll work on that this this afternoon. |
| 12:46 |
jeff |
is your idea to default to localhost if localhost is present in the config and the hostname is not/ |
| 12:46 |
jeff |
? |
| 12:46 |
Dyrcona |
basically. |
| 12:49 |
jeff |
with potentially 255 characters in a terminal password field, why not have sip passwords like: eatery gruntling oilseed puzzleheaded kraken? :-) |
| 12:49 |
jeff |
another option could be 254 random characters copied and pasted. |
| 12:50 |
jeff |
of course, different software will have different max limits. i'm sure few of them have encountered such passwords before. |
| 12:50 |
Dyrcona |
Passwords are great for letting people in, but lousy at keep people out. |
| 12:51 |
bshum |
@dunno add No, you're a puzzleheaded kraken! |
| 12:51 |
pinesol_green |
bshum: The operation succeeded. Dunno #25 added. |
| 12:51 |
jcamins |
jeff: oh no! That was the password I was using for my SIP terminals! Now I'm going to have to change all the passwords! |
| 12:52 |
Dyrcona |
They also don't authenticate a damned thing. |
| 12:52 |
jeff |
jcamins: oh no! "That was the password I was using for my SIP terminals! Now I'm going to have to change all the passwords!" was the passphrase to my ssh key! |
| 12:56 |
Dyrcona |
There's only one password that everyone needs: swordfish. Even Harpo Marx knows that one! |
| 12:57 |
jeff |
Dyrcona: i don't think that we're going to be able to effect a significant change in the current status quo that most/all SIP clients treat auth as either "none required" or "store this username and password either in the clear or in an otherwise reversible fashion". i'm willing to make some improvements within those constraints. |
| 12:57 |
jeff |
Dyrcona: now if you're interested in mocking up some staff interfaces that use certificates or smartcards in the browser... |
| 13:03 |
Dyrcona |
Well, I just got my replacement keyboard from System76, so I think I'll install it. |
| 13:03 |
Dyrcona |
BBL! |
| 13:04 |
tsbere |
jeff: What we need to do is get rid of the SIP clients. Because SIP sucks. ;) |
| 13:04 |
* tsbere |
goes to grab his lunch now |
| 13:07 |
|
smyers__ joined #evergreen |
| 13:10 |
csharp |
SIP_PASSWORD=`shuf -n4 /usr/share/dict/words | tr -d '\n'` |
| 13:25 |
|
Dyrcona joined #evergreen |
| 13:26 |
Dyrcona |
Nice. I like my "new" keyboard. |
| 13:35 |
jeff |
good! |
| 13:36 |
Dyrcona |
I wonder if Clevo will use this keyboard on their other models or if it is exclusive to System76. |
| 13:37 |
Dyrcona |
Anyway, back to Evergreen. |
| 13:58 |
smyers__ |
can someone point me to the documentation of online payment setup? |
| 14:00 |
* bshum |
idly wonders if KCLS ever documented that |
| 14:00 |
bshum |
Since they were the ones who helped have that develop |
| 14:00 |
smyers__ |
I can tell you they didn't |
| 14:02 |
kmlussier |
smyers__: There may be information on that in the archives for the general list. |
| 14:02 |
jeff |
smyers__: did you have any specific questions? |
| 14:03 |
csharp |
smyers__: Lisa Hill was the one who gave me the overview a couple of years back, if that helps |
| 14:04 |
smyers__ |
jeff: yes as soon as the call hits Business::OnlinePayment it dies |
| 14:05 |
smyers__ |
jeff: I think it has something to do with the values in my $argshash->{"processor"} but I am failing at tracing that back to where that is setup |
| 14:06 |
csharp |
ah - well that's beyond what Lisa and I discussed :-) |
| 14:07 |
smyers__ |
csharp: thanks anyway |
| 14:08 |
gdunbar |
smyers__: If you're using paypal or authorize.net you can do just about everything in the staff client... unless I'm misunderstanding |
| 14:08 |
gdunbar |
of course you have to have an active account with one of them to test, too |
| 14:19 |
|
ktomita_ joined #evergreen |
| 14:25 |
|
stevenyvr2 joined #evergreen |
| 14:27 |
smyers__ |
bshum: can I ask which versin of of Busniess OnlinePayment you have? |
| 14:27 |
smyers__ |
perl -MBusiness::OnlinePayment -e 'print"$Business::OnlinePayment::VERSION\n"' |
| 14:30 |
csharp |
smyers__: current version on Ubuntu 12.04 is 3.02 |
| 14:30 |
smyers__ |
thanks csharp same version here |
| 14:43 |
smyers__ |
just to get the fixed logged in case any one else hits something simular Business::OnlinePayment uses backends from Business::OnlinePayment::PayPal in stock evergreen but evergreen can support more like PayflowPro which needs Business::OnlinePayment::PayflowPro |
| 14:46 |
|
sseng joined #evergreen |
| 14:55 |
Dyrcona |
Nothing is ever as simple as it should be. |
| 15:00 |
|
hbrennan joined #evergreen |
| 15:14 |
mmorgan |
If a hold policy says a particular circ modifier not holdable, is there any way to override this and get an item with that circ modifier to capture a hold? |
| 15:23 |
tsbere |
mmorgan: Depends, are you talking from a hold policy POV, or a one-off deal? |
| 15:23 |
mmorgan |
tsbere: One-off deal. There are always exceptions to any rule... |
| 15:24 |
tsbere |
mmorgan: For one-off "I want to place a hold on this regardless of rules" I would look into the "Force" hold functionality |
| 15:25 |
tsbere |
Take note that "regardless of rules" in this case means all rules. The holdable flags on the copy and location will be ignored and hold policies won't even be checked. |
| 15:25 |
|
akilsdonk joined #evergreen |
| 15:27 |
|
mrpeters left #evergreen |
| 15:28 |
mmorgan |
So how does one force a hold? |
| 15:31 |
|
ktomita joined #evergreen |
| 15:31 |
tsbere |
mmorgan: It is a hold type, a copy level variant. You don't place them from the OPAC, but you can from item status. |
| 15:35 |
mmorgan |
"Request Item" must be it. Thought that was a bookings function so overlooked it. Thanks tsbere, I'll look into that. |
| 15:36 |
tsbere |
mmorgan: It does require permission at the item's circ lib to make the request, just so you know. |
| 15:36 |
mmorgan |
okay, thanks! |
| 15:52 |
|
mrpeters joined #evergreen |
| 15:57 |
sseng |
for the self checkout interface, is it possible to pass in via the url the username and password of the staff login (so that, say, a staff wouldn't need to login to authorize the SCKO interface?) |
| 16:00 |
eeevil |
sseng: not without development. and, of course, you can imagine our reluctance to expose a staff-level user/pw combo through something that is relatively easy to retrieve, such as a bookmarked URL |
| 16:00 |
sseng |
eeevil: got it, thanks! |
| 16:20 |
|
akilsdonk joined #evergreen |
| 16:53 |
|
RBecker joined #evergreen |
| 17:09 |
|
mmorgan left #evergreen |
| 17:38 |
|
Bmagic joined #evergreen |
| 17:39 |
Bmagic |
I am new to opensrf for EG 2.4. Should I use open-ils.circ.money.payment to make a payment with my perl script? or is there a better method? |
| 17:55 |
|
dac joined #evergreen |
| 18:03 |
|
kbeswick joined #evergreen |
| 19:04 |
|
rsinger_ joined #evergreen |
| 19:05 |
|
rsinger_ left #evergreen |
| 19:13 |
|
stevenyvr2 left #evergreen |
| 19:38 |
|
fparks_ joined #evergreen |
| 19:44 |
|
eby_ joined #evergreen |
| 19:52 |
|
kmlussier joined #evergreen |
| 21:08 |
|
Callender_ joined #evergreen |
| 21:16 |
|
kmlussier joined #evergreen |
| 21:17 |
|
edoceo joined #evergreen |
| 21:32 |
|
jeff joined #evergreen |
| 21:34 |
|
sseng joined #evergreen |
| 22:02 |
|
artunit joined #evergreen |
| 23:25 |
|
jeff_ joined #evergreen |
| 23:36 |
|
jeff__ joined #evergreen |
| 23:51 |
|
jeff__ joined #evergreen |
