#hypothes.is

<chdorner> morning everybody :wave: :sunny:

<nick> Good morning!

<nick> @chdorner: quick question about the users aggregation

<chdorner> yes

<nick> so, what you've done works just fine

<nick> and we don't need to change it

<nick> but I do wonder if we even need to analyze the user field

<nick> because even with the coming third-party accounts stuff, I think there's going to be an unambiguous mapping from a search string to a userid, so it would perhaps be better to do that in python

<chdorner> you mean turning "username" into "acct:username@hypothes.is" (and all other variations) in python before searching?

<nick> exactly

<nick> although you just turn all the variations into a full acct URI

<nick> not the string into all variations

<nick> but I guess that's what you meant

<nick> i.e. {"username", "username@hypothes.is";, "acct:username@hypothes.is"} → "acct:username@hypothes.is"}

<nick> and eventually {"foo@example.com";, "acct:foo@example.com"} → "acct:foo@example.com"

<chdorner> I meant talking the user input from the query and turning it into a full acct URI (defaulting to "hypothes.is" when no auth domain is set)

<chdorner> ``` foo -> acct:foo@hypothes.is foo@example.org>; -> acct:foo@example.org acct:foo@example.org - acct:foo@example.org ```

<chdorner> but yes, that would mean that we don't have to analyze the user field anymore, and thus we wouldn't need to index the raw userid anymore for aggregating

<chdorner> I didn't want to make mapping changes because of all the troubles that involves

<chdorner> it might make sense to take all these workarounds at the end of the activity pages and then change the mapping and reindex everything in one go

<chdorner> @nick: do you know of a good way to configure env variables for a Jenkins job? looks like people are using: https://wiki.jenkins-ci.org/pages/viewpage.acti...

<nick> sorry -- had to go and receive some parcels for the neighbours

<nick> for Jenkins, do you mean for NPM credentials, or...?

<chdorner> yes, and later on other things as well (chrome webstore api keys, etc.)

<nick> yeah, I don't think that's what you want

<nick> we have the Credentials plugin installed

<nick> and the NPM creds should go in there

<nick> https://jenkins.hypothes.is/credentials/

<nick> in order to get those as ENV vars or whatever into the jobs, I think the right place to look is probably the Credentials Binding Plugin

<nick> https://wiki.jenkins-ci.org/display/JENKINS/Cre...

<nick> See also: https://support.cloudbees.com/hc/en-us/articles...

<chdorner> ah nice

<chdorner> okay

<chdorner> then I'll just have to make sure that they won't show up in the logs (I'm currently getting them into the docker container with `-e`: https://github.com/hypothesis/client/blob/jenki...)

<nick> right

<nick> you might want to just check that you have to do that yourself, actually

<nick> because I think the docker pipeline plugin might be smart enough to forward that part of the environment

<nick> not sure, but it might...

<chdorner> yup, will just have to play around with it for a bit

<nick> > From a Pipeline job, define your credentials, then check Snippet Generator for a syntax example of the withCredentials step. Any secrets in the build log will be masked automatically.

<nick> ^ That's from the docs for the Credentials Binding Plugin

<chdorner> yep, saw that as well

<chdorner> will try it out

<nick> naish

<nick> btw, after all the stuff that merged yesterday, I guess we probably want to do a stage deployment?

<robertknight> Morning all :slightly_smiling_face:

<chdorner> @nick: I did a stage deploy yesterday evening

<nick> oh, did you?

<nick> ha, ok

<nick> sorry

<nick> missed that

<robertknight> @nick: Just had a brief glance at the email from Donald. I can jump in and reply if you'd like, otherwise I can provide a couple of pointers for the issues he raises.

<chdorner> no worries :slightly_smiling_face:

<nick> @robertknight: please do, that would be awesome

<nick> so you did

<nick> oh well

<nick> I deployed again

<nick> for no apparent reason

<nick> :P

<nick> hmmm

<nick> there's something wrong with NIPSA -- doesn't appear to work properly for userids that are mixed-case

<nick> weirdly unflagging and reflagging someone works

<nick> but the bit that's supposed to ensure that new annotations are flagged clearly isn't working properly when the username isn't all lowercase

<nick> right, this is because bulk flagging and individual flagging of annotations doesn't work the same way

<nick> yeurgh

<nick> one for Friday, I think

<robertknight> @nick: Would you have a few moments to look over my question from yesterday about how I'm currently thinking of implementing the login form changes and my question about the best way to customize Deform rendering based on the request's feature flags? - Slack discussion at https://hypothes-is.slack.com/archives/public/p...

<nick> @robertknight: sure -- let me have a quick read

<nick> okay, so for the top-level templates `override_renderer` is kind of your nuclear option

<nick> but it would probably be better if you can to just use `{% if feature('foo') %}...{% else %}...{% endif %}` blocks in the tempaltes

<nick> I'm just looking to see if there's a nice way you could get the `feature` function into the deform template context, too

<seanh> nick: Well, can scripts inside `iframe`s also read cookies if `embed.js` can? I was wondering if there might be a difference between top level page scripts and frame scripts, which might buy us some protection from frame scripts at least

<seanh> But if that's not the case I can save some time constructing tests to find out

<nick> no, but scripts inside iframes can't access the parent window's document, either

<seanh> Ah

<nick> (when the iframe is on a different origin)

<seanh> Ok, well I guess that's the answer then

<nick> so, this is a bit of hack, @robertknight, but I think it's better than the solutions you were discussing yesterday:

<nick> that way you can just use `{% if feature('foo') %}...{% else %}...{% endif %}` everywhere, without having to interfere with views code

<nick> although now I think about it, that should probably go into a `NewRequest` subscriber rather than the `BeforeRender` subscriber, but it'll end up looking about the same

<nick> are you having fun yet @chdorner :P?

<chdorner> argh

<chdorner> quotes, newlines, quotes in passwords, it's ridiculous

<chdorner> plus `npm adduser` is such a pain, you have to pipe in the username, password, and email into it

<nick> oooh, shiny: https://npmcdn.com/hypothesis@0.35.0/build/scri...

<chdorner> maybe somebody can help me quickly, how do I have to quote and escape this: `sh "echo -e \"${env.NPM_USER}\\n${env.NPM_PASS}\\n${env.NPM_EMAIL}\" | npm adduser"` to get this: `echo -e "user\npassword\nemail" | npm adduser`

<nick> `sh "echo '${env.NPM_USER}\\n${env.NPM_PASS}\\n${env.NPM_EMAIL}' | npm adduser"` would be my first guess

<chdorner> the password has single quotes in it though?

<nick> ha!

<nick> change it so it doesn't?

<chdorner> haha, too easy ;)

<chdorner> probably will do :slightly_smiling_face:

<nick> well, you still have the same problem if the password has double quotes in it, so you might as well just change it

<chdorner> I know... :slightly_smiling_face:

<chdorner> it's just so hard to debug

<chdorner> ``` [jenkins-publish] Running shell script + echo ****\n****\n**** + npm adduser npm info it worked if it ends with ok npm info using npm@2.15.8 npm info using node@v4.4.7 Username: Password: npm ERR! cb() never called! ```

<chdorner> not sure if it doesn't try to pipe the echo to npm

<chdorner> or if that's just the output

<robertknight> Ah, yay async programming with callbacks.

<robertknight> Makes debugging much more err... fun that it needs to be

<nick> @chdorner: try adding `-t` to the arfs

<chdorner> to which args?

<nick> docker

<nick> `nodeEnv.inside("-t -e HOME=...")/

<chdorner> what does that do?

<chdorner> ah, TTY

<nick> ensures the command has a TTY from which to read

<chdorner> that's probably a very good point :slightly_smiling_face: let's see what happens

<nick> ``` ~/src/h $ docker run -t node:4 /bin/sh -c "echo 'foo\nbar\nbaz@example.com'; | npm adduser" npm info it worked if it ends with ok npm info using npm@2.15.8 npm info using node@v4.4.7 Username: foo Password: Email: (this IS public) baz@example.com>; npm info attempt registry request try #1 at 10:52:51 AM npm http request PUT https://registry.npmjs.org/-/user/org.couchdb.u...; npm http 401 <https://registry.np

adduser Incorrect username or password npm WARN adduser You can reset your account by visiting: npm WARN adduser npm WARN adduser <https://npmjs.org/forgot>; npm WARN adduser npm ERR! Linux 4.4.15-moby npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "adduser" npm ERR! node v4.4.7 npm ERR! npm v2.15.8 npm ERR! code E401 npm ERR! Registry returned 401 for PUT on <https://registry.npmjs.org/-/user/org.couchdb.

may report this error at: npm ERR! <https://github.com/npm/npm/issues npm ERR! Please include the following file with any support request: npm ERR! /npm-debug.log ```

<nick> works locally, whereas