<asheesh>
That seems aggressively reasonable, maurer. hmm.
<zarvox>
(you can use the X-Sandstorm-User-Id and X-Sandstorm-Session-Id headers instead)
<sprin_>
zarvox: Can you elaborate? I understand that sandstorm only cares about the token supplied in the header for auth, but why can't the cookie be passed through?
<sprin_>
zarvox: what are the properties of the X-Sandstorm ids with respect to anonymous users?
<zarvox>
sending cookies would likely expose apps to CSRF attacks, and cookies are per-origin, so they wouldn't be able to share the API endpoint.
<kentonv>
sprin_: there isn't any way to tell the browser "save this cookie only for requests which have this Authorization token"
<maurer>
asheesh: Hrm, I'm now even more confused, because I tried a totally-unsandboxed version (e.g. can access network, fetch files, etc) and with my makefile patch, it does actually make it all the way past building spk-standalone before dying
<kentonv>
sprin_: so if you set a cookie, it would then apply to all requests sent to the API endpoint from any site in that browser
<maurer>
asheesh: err, not makefile patch. With my seds to fis up the assumptions about e.g. /bin/true, and iptables headers locations
<maurer>
but find . -type l on both that and my failed build dir show the same thing, so that's not the problem
<zarvox>
sprin_: IIRC anonymous users get no X-Sandstorm-User-Id but do get a unique X-Sandstorm-Session-Id.
<sprin_>
oh, I see. I was thinking the API endpoint was on a unique domain per-app
<sprin_>
I suppose I was confusing the proxy to the app's HTTP API with the sandstorm auth API
<zarvox>
no, it's shared between all grains, and routes to the correct grain based on the Authorization token
simonv3 has quit [Quit: Connection closed for inactivity]
<sprin_>
ok, understood. Thanks!
<kentonv>
sprin_: Even if it were unique per app (or grain), it would still be insecure because any site would be able to make requests with that cookie. In general, CORS+cookies is not secure.
<kentonv>
sprin_, zarvox: note that X-Sandstorm-Session-Id is not really reliable as a session identifier since it can be closed at any time
<kentonv>
it's there to allow you to fetch the Cap'n Proto capability associated with the session
<sprin_>
Well, I guess this ties into defining which set of origins are allowed to make CORS requests, as we discussed earlier
<kentonv>
sprin_: Perhaps, but Sandstorm prefers capability-based security rather than ACLs
<sprin_>
Understood. I can write an auth plugin that looks at the Sandstorm headers without much trouble.
<sprin_>
However, if I can't rely on the Session-Id having similar properties to a browser session cookie, things like allow anonymous users to edit their own comments might not work as expected.
<sprin_>
In other words, anonymous users will lose ownership of their objects if X-Sandstorm-Session-Id changes in the middle of their browser session
<kentonv>
sprin_: you can design your protocol such that client-side javascript is responsible for storing a session ID in localStorage (as opposed to having the browser do it, as would happen with set-cookie)
<sprin_>
That seems reasonable!
<kentonv>
it works well since said javascript will be running inside the origin of the client site, rather than the API endpoint's origin
<sprin_>
Thanks for all the help, I am going to start writing the sandstorm auth plugin. I will report back with the results tomorrow.
<kentonv>
sprin_: cool!
neynah has joined #sandstorm
<maurer>
I guess what I don't really get is why when I do some modifications to sandstorm to make it work on nix, then build it, it will work, but if I strip out the part where it fetches sources, and download the same sources into place, it won't build
<kentonv>
maurer: I guess narrow down exactly how the commands you ran differ from what the makefile would run...
<maurer>
Yeah, I will. I just wish I could get ekam to tell me what the problem was, because the error messages don't make any sense :(
<kentonv>
I suspect ekam is as confused as we are. :/
rustyrazorblade has quit [Quit: rustyrazorblade]
funwhilelost has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<zarvox>
looks like /admin/users needs a revamp to deal with the account/identity split
<zarvox>
(unless we intend for it to just show the "primary identity"?)
<asheesh>
+0 to show primary identity
<maurer>
kentonv: So, in an attempt to debug the problem, I tried setting all of the git versions to exactly the ones fetched by a modern one, and trying to build current sandstorm rather than a released version, and it at least appears to have worked (spk-standalone is built in the result, so I just need to patch it so it doesn't try to build the frontend)
<maurer>
kentonv: It looks like the actual issue was that I was failing to guess the deps versions for the release branch I was trying to build
<maurer>
kentonv: do you think it might be reasonable to add '&& git checkout somehash' to the Makefile in the dependencies section on release branches?
<maurer>
(similar to how you have && git checkout stable in libsodium atm)
<kentonv>
I worry that that creates friction against staying current
<maurer>
kentonv: thus why I was only suggesting it on release branches
<maurer>
master would still always clone the latest
<maurer>
but the release branch wasn't building for me b/c I couldn't guess the right mix of revisions
<maurer>
(I've now got a set which builds, so I can lock to that for a bit)
<kentonv>
the latest cap'n proto should work with all releases going back a long time...
<maurer>
I mean, I don't know what the issue was, but I tried latest release, and master for all deps, that failed
<maurer>
in the way shown above
<kentonv>
is this reproducible? I'd love to poke at it.
<kentonv>
the errors you reported don't look like version skew
bb010g has quit [Quit: Connection closed for inactivity]
<maurer>
kentonv: Well, unskewing versions got rid of the errors
<maurer>
(just look at the rev lines, the rest of it is build context)
<kentonv>
oh you had cap'n proto at 0.5.3?
<maurer>
That's the latest release
<kentonv>
sandstorm and cap'n proto are developed together, and sandstorm depends on features that aren't in any release
<kentonv>
so that would break everything, yes
<maurer>
Oh, I figured that the release branch of sandstorm would work with the release branch of capnproto
<kentonv>
sorry, it doesn't. (this is mentioned in the readme, I think...)
* maurer
checks
<kentonv>
huh the readme is a lot shorter than it used to be
<maurer>
I don't see any mention in the readme or the install docs
<maurer>
It's still kind of my bad
<maurer>
but I got super surprised by the ekam errors
<kentonv>
hmm, I guess maybe we figured it wasn't relevant to include in the readme anymore when we changed the makefile to fetch cap'n proto itself
<maurer>
Yeah, I'm trying to get the whole thing to build in an environment where downloading things during the build is considered not OK
<maurer>
since it wants all builds to be reproducible
<kentonv>
but yeah, sorry for the confusion
<maurer>
Yeah, it still seems like it wouldn't be too hard to list commit ids when a dependency is cut
<maurer>
err
<maurer>
when a release is cut rather
<maurer>
but if you're super against it, it's your project
<maurer>
(I understand the desire to pull master when on master to avoid getting behind)
<kentonv>
well, we don't actually have release branches at present, we just tag the commit where the release happened
<kentonv>
can git tags have descriptions? Could we put it there?
<maurer>
git tags can have descriptiosn
<maurer>
*descriptions
<maurer>
They're referred to as "annotations" in the documentation for git
<kentonv>
we should be able to stuff the dependency git revisions in there, then
<maurer>
Seems an odd place to put it, but probably only seems that way to me because I'm mentally used to having a release branch
<maurer>
Yeah, I'd be happy with that
<maurer>
thanks for bearing with me, I know that I seem to have super obscure concerns here
<kentonv>
we do plan to have release branches eventually, and chrome-like stable/beta/dev channels, but not until 1.0-ish
<maurer>
Sure, makes sense
<maurer>
Also, looks like someone has managed to package meteor since the last time I tried this
<maurer>
so not today, but I might be able to get sandstorm-the-server packaged eventually
<kentonv>
and arguably we should be using git submodules, but that adds friction when I want to make little changes to cap'n proto for immediate use in sandstorm, which I do pretty often.
<kentonv>
on my machine "deps" is actually a symlink to "..", i.e. to the directory where I check out all my projects
<maurer>
kentonv: I mean, git submodules have ups and downs, but they do seem to match pretty closely what ekam wants
<maurer>
The problem is that submodules only really work well if people dev on one project at a time, which is what you're describing not doing :P
mnutt_ has quit [Quit: mnutt_]
ripdog has joined #sandstorm
bb010g has joined #sandstorm
joshbuddy has quit [Quit: joshbuddy]
TC01 has quit [Ping timeout: 260 seconds]
TC01 has joined #sandstorm
jadewang has quit [Remote host closed the connection]
sprin_ has quit [Quit: Lost terminal]
funwhilelost has joined #sandstorm
sprin has joined #sandstorm
simonv3 has joined #sandstorm
funwhilelost has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jadewang has joined #sandstorm
jadewang_ has joined #sandstorm
jadewang has quit [Read error: Connection reset by peer]
simonv3 has quit [Quit: Connection closed for inactivity]
bb010g has quit [Quit: Connection closed for inactivity]
bb010g has joined #sandstorm
joshbuddy has joined #sandstorm
rustyrazorblade has joined #sandstorm
rustyrazorblade has quit [Client Quit]
funwhilelost has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
joshbuddy has quit [Quit: joshbuddy]
joshbuddy has joined #sandstorm
<gwillen>
hmmm, with the Wekan sandstorm app, is it the case the only the owner of a grain can edit the labels (not anybody with write access?) Is that hardcoded / can we change it?
<sprin>
I am trying to send anonymous clients an Id to be stored in sessionStorage. Normally, this would be sent in a signed cookie, but lacking that, I would send it in a signed header.
<mnutt_>
(actually that list I sent you are the request whitelist, rather than a response whitelist, sorry)
<sprin>
ah, thanks for the link. I would rather not ask for a new header to be whitelisted, since I am writing this identity plugin from scratch, so I am looking for the sanctioned approach.
<mnutt_>
you could probably (ab)use one of the headers that already gets passed through
<sprin>
I'd rather not have to ;)
<sprin>
I don't really want to change the API format to send it in the response body though
<sprin>
I suppose I could send the id from a different endpoint altogether, rather than just piggy-backing on any API request. But this means I need to work in an extra request before any "identity-requiring" API calls are made.
rustyrazorblade has joined #sandstorm
<sprin>
Hmm, I can't supply the Id on just any API response, it breaks caching. So I think my options are to create a separate endpoint solely for the purpose of generating an Id for new identities (anonymous browser sessions), or to ask for a header to be whitelisted, so the app can send the Id along with any API request.
<zarvox>
dwrensha: so, the setPath issue appears to be a broader "switching identities doesn't work" because the GET of /_sandstorm-init doesn't include a sessionId query param, and 404s.
<dwrensha>
I think it always 404s, then recovers?
<zarvox>
oh, yes, perhaps it's making another request thereafter
<zarvox>
ahhh, right you are
<zarvox>
except both of these are using path=/ ;_;
<zarvox>
why are we making the request that 404s? overly enthusiastic reactivity?
<dwrensha>
shrug
<sprin>
Thinking this through, I think I would like to have an "X-Session-Id" header allowed in the request/response. This header would represent a signed Id value that is tied to an anonymous user's browser session. Functionally, it is a like a session cookie, except that the JavaScript client must extract the id from sessionStorage before making API requests.
<dwrensha>
I have noticed that I usually see an ugly error screen briefly when I'm switching identities
<pdehaye>
All you need to do is configure the SMTP Url field under Admin Settings to a working SMTP server that will accept e-mails with the SMTP envelope's bounce address set to your grain's local address. —->
<pdehaye>
what is the grain’s local address? should it be subdomain, if i m using sandcat?
<asheesh>
That's a long way to say "an SMTP server".
<asheesh>
A grain's local address is {{publicId}}@yourname.sandcats.io
<pdehaye>
if i look at mailgun, for instance, i don t think it s possible for me to do this with the free tier
<pdehaye>
first step for verifying is to go to my DNS provider
<asheesh>
Yeah, I think that's right. I need to fix that at the sandcats level |:
<pdehaye>
FWIW, mandrill looks like it is working better
<asheesh>
Excellent.
<asheesh>
Thank heavens.
<pdehaye>
or at least it doesn t ask to verify as overtly, it works with the free tier right away
bb010g has quit [Quit: Connection closed for inactivity]
<larjona>
asheesh I tried Davros today, with owncloud client from debian-stable-backports, and it works :)
<zarvox>
:D
<asheesh>
larjona: Yay (-:
<asheesh>
...remind me, why do we even let the app know its per-session subdomain?
<asheesh>
Presumably life would be easier if the Host: header were stripped before the app even saw the request.
<zarvox>
Because a lot of apps expect the Host: header so they can generate absolute links :/
<asheesh>
Right, which secretly actually just leads to sadness.
<zarvox>
I agree that we'd all be better off if they just used relative links
<asheesh>
More pain now means less pain later. I'm sometimes hard to convince by this argument, but here I am promoting it.
<asheesh>
So, go figure.
<asheesh>
Presumably we could make this an option for sandstorm-http-bridge and transition the world if we decide it's a good idea.
<asheesh>
Also hi from laptopping at hair salon while waiting for a haircut.
joshbuddy has joined #sandstorm
NOTevil has quit [Quit: until next time...]
<sprin>
I just set up a sandstorm dev environment here to try poking at allowing an additional header through
<sprin>
sandstorm compiles fine after getting all the deps (ekam is quite fascinating)
<sprin>
but sandstorm refuses to start with an error from mongod: SEVERE: Failed global initialization: BadValue Invalid or no user locale set. Please ensure LANG and/or LC_* environment variables are set correctly.
<sprin>
It looks sandstorm is setting up a new namespace for itself and mongo
<sprin>
dwrensha: ah, I see
<dwrensha>
sprin: what distro are you using?
<sprin>
fedora 22
<dwrensha>
ah, I think zarvox has hit the same issue on fedora
<dwrensha>
I think my workaround in Arch doesn't work in Fedora, for some reason
<sprin>
I will give it a try.
<sprin>
dwrensha: how do I update sandstorm with the results of `make continuous`?
<dwrensha>
make update
<dwrensha>
I typically have one terminal that's running `make continuous` always
<dwrensha>
and then in another I do `make update`
<sprin>
ah, I did not install sandstorm to run a service, so `make update` did not work
<sprin>
this seemed to work though: make sandstorm-0-fast.tar.xz && ~/sandstorm/sandstorm update ~/repos/sandstorm/sandstorm-0-fast.tar.xz
<sprin>
I should just install sandstorm as a service so `make update` works
<sprin>
ah, it looks like the sandstorm binary needs to be on root's path for `make update`
<dwrensha>
oohh
<dwrensha>
did you install as a non-root user?
<sprin>
ah, well, it works! mongo is able to start now, and it looks like the server is running fine
<sprin>
yes, it's running under my user
<dwrensha>
sounds like a Makefile bug then
<dwrensha>
`make update` should not try to be root if the install isn't root
<sprin>
yes, seems so. I can file a bug if you like
<dwrensha>
sprin: you should file a bug
<sprin>
sure
<dwrensha>
sprin: how did you get the locale thing to work?
<sprin>
you workaround did the trick, I think.
<dwrensha>
interesting!
<dwrensha>
zarvox: ^ how does this compare to your experience on Fedora?
rustyrazorblade has joined #sandstorm
itscassa is now known as itscassa|away
<sprin>
dwrensha: I can confirm your workaround solved it for me on fedora 22. I deleted the new locale, compiled, updated, and mongo failed to start again. Then I redefined the C.UTF-8 locale, compiled, updated, and mongo started successfully.
<dwrensha>
good to know
<zarvox>
localedef fails on my machine, or the output that it creates is not useful, or something
<zarvox>
also I appear to have run out of disk space on /, which is getting in the way of things
<asheesh>
i,i "the execution of all things"
<zarvox>
okay, space retrieved, but still: localedef doesn't actually create a C.UTF-8 locale when I run it O_o
<zarvox>
do I need some particular set of locale devel packages installed or something?
<zarvox>
or do I need to run some command to extract the locale from /usr/lib/locale/locale-archive?
joshbuddy has quit [Quit: joshbuddy]
<zarvox>
well, if I specify an absolute path for output, things appear to generate some LC_* files
<zarvox>
they are substantially smaller than their Debian-generated counterparts, though, which bothers me
aaronr has quit [Remote host closed the connection]
<zarvox>
mnutt_: Oh hey, nice! I assume you're using the same implementation technique that piwik used for analytics?
<mnutt_>
zarvox: yeah, X-Sandstorm-Passthrough and X-Real-IP
<mnutt_>
unfortunately analytics apps can’t support analytics from IE9 and below since those IEs have weird CORS support that doesn’t allow setting headers.
<mnutt_>
hopefully that causes everyone to forget about them and make them go away faster :)
<zarvox>
mnutt_: ahhh, you embed the whole JS in the copyable snippet
<mnutt_>
yeah, it’s simple enough that I figured it’d be easiest to put the whole thing in there. I started out with a bunch of cross-platform hacks and stripped them out as I realized they didn’t work
joshbuddy has joined #sandstorm
<zarvox>
Heh.
<sprin>
zarvox: when I do: sudo localedef --list-archive | head -n1
<zarvox>
If you later decide you need more code so you can do more than just make a single xhr on pageload, you can always static-publish some JS, and script src it in.
<sprin>
I get: C.utf8
<sprin>
Which confused me, because I would have expected C.UTF-8, not C.utf8
<zarvox>
sprin: I also get this, but I don't see the /usr/lib/locale/C.UTF-8/ getting generated that appears to be the thing we care about pulling in when building on Debian.
<zarvox>
Also, /usr/lib/locale/locale-archive is 103MB, which I think is larger than we intend for the bundle to be.
<sprin>
hmm, I don't have that on my machine either.
<zarvox>
whaaaaaat what's localedef --list-archive reading from on your machine then?
<sprin>
ah, I do have /usr/lib/locale/locale-archive, but not /usr/lib/locale/C.UTF-8/
<zarvox>
I'm kinda hoping we can make make-bundle.sh generate an appropriate C.UTF-8 locale folder under the bundle root