| Time |
S |
Nick |
Message |
| 00:32 |
|
|
peterbull joined #dvn |
| 02:52 |
|
|
iqlogbot joined #dvn |
| 02:52 |
|
|
Topic for #dvn is now http://thedata.org - The Dataverse Network Project | logs at http://irclog.iq.harvard.edu/dvn/today |
| 13:13 |
|
|
posixeleni joined #dvn |
| 13:13 |
|
posixeleni |
pdurbin: good morning |
| 13:14 |
|
pdurbin |
posixeleni: hi! I was just re-reading yesterday's chat |
| 13:15 |
|
posixeleni |
pdurbin: any questions? I'm going to work adjusting on the high level workflow doc https://docs.google.com/document/d/1COP7Qg9XjPnaxTqG-dSgB8tq3X504QOCm9A7lk4Iqaw/edit |
| 13:16 |
|
posixeleni |
to reflect that data deposit API will kick in at Journal Article Approval not at Journal Article Publishing |
| 13:16 |
|
posixeleni |
by default |
| 13:18 |
|
pdurbin |
posixeleni: one quick meta question... that doc you just linked to. the "working copy"... does that eventually get merged into one of the docs listed at http://projects.iq.harvard.edu/ojs-dvn/book/project-documentation ? |
| 13:19 |
|
posixeleni |
pdurbin: yes! I will be updating also this one which is for publishers https://docs.google.com/document/d/1Mqqx4bB9FZFZhW8xZYnDpHOcT4p57asNJoLNf9Mof0I/edit |
| 13:20 |
|
pdurbin |
right right. ok |
| 13:20 |
|
pdurbin |
I'm not in the habit of checking the working copy for updates |
| 13:23 |
|
posixeleni |
working copy just has more details that would be relevant to us ATM but might not really make sense for people reading the website |
| 13:23 |
|
pdurbin |
right |
| 13:24 |
|
posixeleni |
like the whole question of an API key instead of username/password login |
| 13:30 |
|
pdurbin |
posixeleni: sure. that's certainly an implementation detail :) |
| 13:31 |
|
pdurbin |
it's a valid concern... that since passwords are sent via SWORD they must be stored either unencrypted or with reversible encryption |
| 13:32 |
|
pdurbin |
as long as the passwords are sent over HTTPS they are encrypted along the way |
| 13:34 |
|
posixeleni |
does SWORD allow for that type of encryption ? |
| 13:36 |
|
pdurbin |
posixeleni: well, http://swordapp.github.io/SWORDv2-Profile/SWORDProfile.html#authenticationmediateddeposit is the section to focus on: 8. Authentication and Mediated Deposit |
| 13:36 |
|
pdurbin |
"implementations MUST support HTTP Basic Authentication in conjunction with a TLS connection" |
| 13:36 |
|
pdurbin |
that's what I'm doing right now |
| 13:36 |
|
pdurbin |
hmm |
| 13:36 |
|
pdurbin |
actually, I should include the full quote |
| 13:37 |
|
pdurbin |
"In [AtomPub] Section 14, implementations MUST support HTTP Basic Authentication in conjunction with a TLS connection. The SWORD Profile relaxes this requirement: SWORD client and server implementations SHOULD be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection as specified by [RFC2818]." |
| 13:38 |
|
pdurbin |
posixeleni: in all of my testing I'm sending passwords over HTTPS |
| 13:42 |
|
posixeleni |
pdurbin: so the API Key would be redundant to have? |
| 13:43 |
|
pdurbin |
posixeleni: API key? what API key? |
| 13:43 |
|
posixeleni |
pdurbin: if we had journals put in an API Key in OJS plugin instead of username and password |
| 13:44 |
|
pdurbin |
hmm |
| 13:44 |
|
posixeleni |
am i misunderstanding this? |
| 13:45 |
|
pdurbin |
no no, it's a great idea but a fair amount of work. probably not a v1 thing |
| 13:45 |
|
pdurbin |
for a long time Twitter users would complain that they would have to give a third party website their actual Twitter password to tweet on their behalf |
| 13:45 |
|
posixeleni |
ok will make a note for v2 implementation consideration |
| 13:46 |
|
posixeleni |
yeah flickr too |
| 13:46 |
|
pdurbin |
and eventually Twitter implemented OAuth |
| 13:46 |
|
pdurbin |
yeah |
| 13:46 |
|
pdurbin |
which solves this problem |
| 13:46 |
|
pdurbin |
but that took years to develop |
| 13:47 |
|
pdurbin |
posixeleni: maybe we should have a Redmine ticket about this... for v2 of the Data Deposit API |
| 13:48 |
|
posixeleni |
want me to ask Gustavo? |
| 13:48 |
|
posixeleni |
he brought this up to me in the 1st place |
| 13:49 |
|
pdurbin |
I'll just make one quick |
| 13:55 |
|
pdurbin |
posixeleni: how does this look? https://redmine.hmdc.harvard.edu/issues/3208 |
| 14:00 |
|
* posixeleni |
looks at redmine |
| 14:04 |
|
posixeleni |
pdurbin: makes sense! also thanks for commenting on the working copy |
| 14:05 |
|
* posixeleni |
high fives pdurbin |
| 14:05 |
|
pdurbin |
lol |
| 15:24 |
|
|
peterbull joined #dvn |
| 15:24 |
|
peterbull |
howdy |
| 15:28 |
|
pdurbin |
peterbull: hello hello. I have you a shout out at [sword-app-tech] SWORD community development and support - http://www.mail-archive.com/sword-app-tech@lists.sourceforge.net/msg00333.html :) |
| 15:29 |
|
pdurbin |
and I also asked about the API key thing: [sword-app-tech] using API keys (OAuth?) rather than HTTP Basic Authentication (username/password) in conjunction with a TLS connection - http://www.mail-archive.com/sword-app-tech@lists.sourceforge.net/msg00334.html |
| 15:41 |
|
peterbull |
not sure if you've seen this, but there seems to be a little bit of chatter about oauth on a swor list: http://www.mail-archive.com/sword-app-techadvisorypanel@lists.sourceforge.net/msg00141.html |
| 15:50 |
|
pdurbin |
peterbull: no, I hadn't seen this. thanks. looks like Richard, the SWORDv2 spec lead said, "I'm quite interested in OAuth (or similar) for security and mediated deposit, but the implementation overhead is fairly significant." |
| 15:51 |
|
pdurbin |
peterbull: huh. this is a different mailing list! interesting. now I know to search this one too |
| 15:52 |
|
pdurbin |
anyway, I agree with "fairly significant" |
| 15:53 |
|
pdurbin |
which is why I was saying this seems like a v2 thing for the DVN Data Deposit API |
| 15:58 |
|
peterbull |
yeah, that sounds about right given what I've read about implementing oauth |
| 15:59 |
|
peterbull |
@pdurbin are we using the In-progress flag on the dvn side? if so, what does it mean? |
| 16:00 |
|
* peterbull |
reads http://www.ircbeginner.com/ircinfo/ircc-commands.html |
| 16:01 |
|
pdurbin |
peterbull: "As scholarly systems may wish to give the client more control over the publishing process, SWORD uses the In-Progress HTTP header [SWORD001] to allow the client to indicate that a deposit should not yet be injected into any post-submission or pre-publication workflow." -- http://swordapp.github.io/SWORDv2-Profile/SWORDProfile.html#continueddeposit |
| 16:02 |
|
pdurbin |
peterbull: and no, I'm not checking for that header. not yet anyway |
| 16:03 |
|
pdurbin |
peterbull: but this very well may be a good way to change a study from "draft" to "released" |
| 17:05 |
|
|
peterbull joined #dvn |
| 17:55 |
|
|
peterbull joined #dvn |
| 18:13 |
|
|
peterbull1 joined #dvn |
| 19:12 |
|
|
peterbull joined #dvn |
| 19:19 |
|
pdurbin |
peterbull: this just in: "no attempt to use OAuth with SWORD that I'm aware of" -- http://www.mail-archive.com/sword-app-tech@lists.sourceforge.net/msg00340.html |
| 19:23 |
|
peterbull |
#trailblazers |
| 19:24 |
|
pdurbin |
heh |
| 19:25 |
|
pdurbin |
peterbull: when you're done with your sword client you can implement oauth for us ;) |
| 19:26 |
|
peterbull |
pdurbin: nothing would make me happier |
| 19:26 |
|
pdurbin |
:) |
| 19:29 |
|
peterbull |
pdurbin: presumably "get_atom_sword_statement" is what I want to get the list of files in a study? |
| 19:36 |
|
pdurbin |
peterbull: hmm, that might make more sense than where I've put it for now: https://github.com/IQSS/dvn/blob/develop/tools/scripts/data-deposit-api/test-collection-get |
| 19:43 |
|
peterbull |
pdurbin: ah, i see. i'll see if i can make the python-client hit that |
| 20:56 |
|
pdurbin |
peterbull: ok, but it's subject to change |
| 20:57 |
|
peterbull |
pdurbin: well, i can get it as is for now. however, i don't see all the study-level data in the response. e.g., missing author and abstract |
| 23:49 |
|
|
peterbull joined #dvn |
