treyhunner has quit [Quit: No Ping reply in 180 seconds.]
treyhunner has joined #sandstorm
mnutt__ has joined #sandstorm
<mnutt__>
are there explicit reasons to not allow arbitrary HTTP headers through the proxy and legacy bridge, at least for API calls? I’m wondering because it seems reasonable to allow HTTP APIs to use custom headers, but impossible to enumerate all of them in web-session. The backstory is that I got through porting all of the basic webdav calls, but at the last minute realized my desktop client uses some custom proprietary HTTP header
<mnutt__>
for chunked uploads that obviously don’t need to be added to sandstorm itself.
treyhunner has quit [Quit: No Ping reply in 180 seconds.]
treyhunner has joined #sandstorm
<kentonv>
mnutt__: Yes. (1) If an app can send arbitrary headers it can potentially spoof Sandstorm headers; blacklisting those is fragile. (2) A lot of HTTP headers have more to do with the connection than the resource and so don't make sense once things have gone to Cap'n Proto. (3) Sometimes HTTP headers leak private information which we don't want apps to see. For example, supercookies.
<kentonv>
Also in category (3), reverse proxies often add things like IP address and such, on the assumption that everything behind them is trusted. But Sandstorm apps are not "trusted".
<kentonv>
mnutt_, mnutt__: Please send a mail to sandstorm-dev or file an issue describing the custom headers your app uses. I'm happy to consider whitelisting specific things.
<mnutt__>
will do. they’re just very specific to the client/app in question, and I was really hoping to not have to fork the (already built, open-source) client
<mnutt__>
but I may have to. the protocol is 99% webdav but for some reason for the last 1% they decided to add some special “oc-chunked” headers and special handlers for uploading files in chunks.
<kentonv>
We should probably institute a general whitelist where we feel comfortable adding lots of app-specific headers. If it's just adding one line to a list then it's not too hard to justify doing it even for a one-off app.
<mnutt__>
good to know that’s the direction we’re headed. right now it involves updating in a bunch of places
gopar has quit [Remote host closed the connection]
bpierre_____ has quit [Ping timeout: 244 seconds]
decipherstatic has quit [Ping timeout: 244 seconds]
itscassa|away has quit [Ping timeout: 250 seconds]
itscassa|away has joined #sandstorm
jadewang has quit [Remote host closed the connection]
jadewang has joined #sandstorm
jadewang has quit [Remote host closed the connection]
jadewang has joined #sandstorm
jadewang has quit [Remote host closed the connection]
paroneayea has quit [Ping timeout: 260 seconds]
xcombelle has joined #sandstorm
JWK has quit [Quit: JWK]
mort___ has joined #sandstorm
JWK has joined #sandstorm
JWK has quit [Client Quit]
jadewang has joined #sandstorm
JWK has joined #sandstorm
jadewang has quit [Ping timeout: 246 seconds]
JWK has quit [Quit: JWK]
JWK has joined #sandstorm
JWK has quit [Ping timeout: 265 seconds]
JWK has joined #sandstorm
JWK_ has joined #sandstorm
JWK has quit [Ping timeout: 256 seconds]
JWK_ is now known as JWK
JWK has quit [Quit: JWK]
JWK has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 260 seconds]
JWK has quit [Quit: JWK]
JWK has joined #sandstorm
amyers has joined #sandstorm
amyers has quit [Remote host closed the connection]
JWK has quit [Quit: JWK]
amyers has joined #sandstorm
JWK has joined #sandstorm
treyhunner has quit [Quit: No Ping reply in 180 seconds.]
treyhunner has joined #sandstorm
mort___1 has joined #sandstorm
mort___ has quit [Ping timeout: 246 seconds]
mort___1 has quit [Quit: Leaving.]
mort___ has joined #sandstorm
jadewang has joined #sandstorm
natea has quit [Quit: natea]
jadewang has quit [Ping timeout: 245 seconds]
natea has joined #sandstorm
mnutt_ has quit [Quit: mnutt_]
mnutt_ has joined #sandstorm
jadewang has joined #sandstorm
mnutt_ has quit [Client Quit]
jadewang has quit [Ping timeout: 240 seconds]
paroneayea has joined #sandstorm
dwrensha_ has joined #sandstorm
dwrensha has quit [Ping timeout: 244 seconds]
dwrensha_ is now known as dwrensha
mnutt_ has joined #sandstorm
amyers has quit [Ping timeout: 264 seconds]
jadewang has joined #sandstorm
mort___ has quit [Ping timeout: 246 seconds]
jadewang has quit [Ping timeout: 256 seconds]
NOTevil has joined #sandstorm
JWK has quit [Quit: JWK]
mnutt_ has quit [Quit: mnutt_]
mnutt_ has joined #sandstorm
neynah has joined #sandstorm
jadewang has joined #sandstorm
JWK has joined #sandstorm
natea has quit [Quit: natea]
<ocdtrekkie>
mnutt_: super exciting stuff!
natea has joined #sandstorm
<paulproteus>
mnutt_: Yeah! Wowee. I actually said "Wow!" out loud when I saw the sandstorm-dev email.
<mnutt_>
paulproteus: thanks! sorry I never emailed you about it, but you can follow along with the davros repo and I’ll let you know when it’s in a semi-usable state
<paulproteus>
I'm not sorry; if you didn't need to email me, then I'm A-OK with you not emailing me!
<paulproteus>
I'm going to watch your YouTube video now.
prosodyContext is now known as misalias
<mnutt_>
the one thing that feels a little off about the integration is that you can only connect to one grain at a time with the Mirall client. So most users will probably only ever have a single grain. I may eventually fork mirall to allow separate connections, since that would mean that you could get much more fine-grained sharing abilities. Maybe even someday on par with dropbox, it would be pretty cool.
<paulproteus>
Wow!
<paulproteus>
The UI in the beginning, you could maybe patch it to parse the special Sandstorm formatted https://url#bearertoken thing
<mnutt_>
yeah, that would be killer.
<paulproteus>
It'd be nice to upstream that.
<paulproteus>
If they'd accept the patch. It'd be nicer if the URL structure could somehow clearly indicate SANDSTORM all over it, like if it were https://{{url}}#SANDSTORM_TOKEN={{bearer_token}}
<mnutt_>
that’s another thing I’m a little unsure of, I have no idea how the owncloud people will view this. but I guess worst-case, it’s a fork.
<paulproteus>
That way no one is going to get confused.
<paulproteus>
Yeah, I'm unsure of that too, honestly.
<paulproteus>
I did meet them, so you could email the main person and CC: me and see what they think.
<mnutt_>
maybe it’d push them to port owncloud itself :) which would be a piece of cake after all of the webdav work I did
<paulproteus>
(-:
<paulproteus>
I'm sure they'd prefer having an OwnCloud package to having your random backend. : D
<paulproteus>
Your random backend looks very very nice though, honestly.
<XgF>
I really want a "directory" sandstorm grain, where every file is another grain
<paulproteus>
Oh my.
<XgF>
(not sure how you'd handle that & webdav. Maybe ".sandstormgrain" files would be capnp bundles of the grain data?)
<paulproteus>
How about a CSV file sandstorm grain, with each row being a grain? : P
<XgF>
(if the grain didn't expose a webdav interface)
<paulproteus>
(But I jest.)
<XgF>
paulproteus: But one of the reasosn for this is that then you could use shared directories to share bundles of stuff
<XgF>
Also it ties in well with the document-per-rgain model
<paulproteus>
Yeah, exactly; I do see the upside.
jadewang has quit [Remote host closed the connection]
<mnutt_>
I think webdav could actually make that work. crazy.
<mnutt_>
you do a PROPFIND on the root directory, it returns back some XML that lists the contents, and those are grain URLs
<mnutt_>
I think the mirall client I’m using makes some assumptions about directory structure that would need to be changed and is probably outside of the scope of this particular app, but theoretically you could build a webdav client that used grain-per-file
<mnutt_>
right now the client infers where the file is located on the server from the local directory structure, it would need to save the grain location in metadata somewhere
<paulproteus>
(It came up when discussing this with myself on #opensourcedesign)
<paulproteus>
Also "This page is a placeholder" is extremely confusing at https://sandstorm.io/apps/ ; it makes it seem like the apps aren't even real.
<paulproteus>
But of course https://sandstorm.io/apps/ is going away so it's not like I need us to fix that. (-:
<kentonv>
paulproteus: Yes, unfortunately the "filter for open source" requirement got lost somewhere in the app store's development.
<paulproteus>
Yeah, I remember that getting lost, hence "surely annoying".
bb010g has joined #sandstorm
mnutt_ has quit [Quit: mnutt_]
mort___ has quit [Quit: Leaving.]
JWK has joined #sandstorm
<dwrensha>
ugh IronRouter. the `onRun()` callback is defined to run only once. And yet `Tracker.active` is true inside the callback. Whyyy? Howw?
<dwrensha>
aha, Tracker.active remains true after you call `computation.stop`. Which is annoying.
<paulproteus>
alpha.sandstorm.io is one Sandstorm server we (the company behind Sandstorm) maintain, although eventually it'll probably go away and get folded into the hosting service that we're now working on called oasis.sandstorm.io.
<dwrensha>
... forcing me to use Tracker.nonreactive(), I think.
JWK has joined #sandstorm
<paulproteus>
BTW howdy JWK, I don't think we've chatted much here, welcome to #sandstorm and let me know if you have any questions!
JWK has quit [Client Quit]
mort___ has joined #sandstorm
<zarvox>
dwrensha: what are you trying to do here?
<dwrensha>
make it so we only need to call openSession() once
<j^>
paulproteus: will have a look at packaging some time next week.
<paulproteus>
Cool (-: I'm always happy to answer questions; best email is probably community@sandstorm.io. Also I guess I'll be in Boston & available this coming Friday daytime and Sunday morning, if you're based there....
<dwrensha>
I think I might define a function `onceTrue(reactiveConditionFunction, continuation)`
<zarvox>
Ahhh. I guess you could make openSession idempotent and reentrant, and have it call this._dep.depend(), and only call this._dep.changed() when it actually makes changes?
<dwrensha>
zarvox: no, I make this._revealIdentity a ReactiveVar
<zarvox>
i,i call/cc
<j^>
paulproteus: not from boston but will email you or ask here if i have questions
<dwrensha>
c.c
<zarvox>
dwrensha: ah, that also works
<zarvox>
probably simpler too :)
<dwrensha>
and I don't want it to need to be reentrant
<dwrensha>
just, when it gets called, it should wait until it can continue
gillisig has joined #sandstorm
<dwrensha>
I have this working on my branch. Just simiplifying it now
<paulproteus>
Doing that hinges on the Sandstorm codebase growing a few more features, though, so it's not something that's easily doable right now.
<dwrensha>
zarvox: you could tell the raft-rs people that if they update their capnp dependency they can use generics. :)
<paulproteus>
zarvox: or stubmit a pull request to them : D
<paulproteus>
bb010g: Another difficulty is that Phabricator command line tools expect one way of communicating with Phabricator, but that may or may not need some adjustment to conform to https://docs.sandstorm.io/en/latest/developing/http-apis/ (but should be totally doable, even if it does require some small adjustment)
<paulproteus>
So I say "monolithic" package as opposed to something more "granular", like how with Etherpad we have one pad per app instance, which limits security damage in the case that Etherpad has a bug where having access to one pad gives you (due to a security issue) access to another pad.
<zarvox>
dwrensha: will do :)
<paulproteus>
You could imagine a more "granular" Phabricator package, where each git repo hosted by Phabricator is a separate "grain" in Sandstorm. But Phabricator has a nice UI for managing multiple repositories, so all in all, a "monolithic" package is almost definitely the right starting point for now.
<paulproteus>
And to actually answer your question bb010g I think it would be fairly easy to start from the packaging tutorial and install Phabricator and make an initial package.
<paulproteus>
bb010g: Are you possibly interested in doing so? : D
<bb010g>
paulproteus: Thanks for the info. Yeah, possibly in the future. I'm always surprised I don't see it in use more because its code review tools are awesome, and putting it on Sandstorm would probably help with that.
<paulproteus>
Agreed. I used to work at Eventbrite and I remember they were strongly considering switching to it.
<dwrensha>
zarvox: I'm astounded that IronRouter does not provide an `onReady()` hook
<dwrensha>
`this.ready()` may be false in `onRun()`
<paulproteus>
Howdy KaZeR , welcome to the Sandstorm.io IRC channel, and feel free to let me know if you have any questions. Feel free to also be quiet and "idle", many people do that here too.
<zarvox>
dwrensha: ^ this fixes the stuck on Loading... bug and the "identicons for grains in sidebar when route is /grain/<grainId>"
<paulproteus>
BTW mnutt_ if you'd be willing to give a talk at New York Linux Users Group, I bet they'd love to hear about Sandstorm. I know they're looking for speakers, and I know one of the organizers.
<paulproteus>
Not something you need to commit to right away, but something that I think would be amazing if you could do it, so I might mention it periodically and see what your level of interest is. We do have some slides you can base a talk on: https://blog.sandstorm.io/news/2015-02-27-speaker-kit.html
<mnutt_>
paulproteus: sounds awesome, my schedule over the next month or two is a little busy but it’s something I’m generally interested in
<paulproteus>
Also kentonv I incorrectly claimed mnutt_ was using an off-the-shelf WebDAV UI; even the web frontend is pure mnutt_.
<paulproteus>
Also I'm fascinating that you used Ember. I'd _love_ to see Ember people get more into Sandstorm over time.
<paulproteus>
s/fascinating/fascinated.
<paulproteus>
I remember getting some enthusiasm from other Ember people, but I can't seem to remember who.
<mnutt_>
yeah definitely. I would love to see more open source apps built in ember, and sandstorm is a great way to distribute open source apps
<mnutt_>
ember has a great open source community but not too many examples of fully built open source ember apps
<paulproteus>
This is not a way you can support Sandstorm.
<paulproteus>
(It did show up in my automatic Google querying though!)
<paulproteus>
kentonv: Quick question, hoping for sanity-check: If I made a "Sandstorm self-hoster self-diagnostics" app, that would be reasonable to live in the App Marketplace, right?
<paulproteus>
I guess there are things it wouldn't be able to do, but there are things it would be able to do, which is nice. Things it could do: * Test WebSockets. * Test if you're using HTTPS (based on inbound headers to the app). * Send outbound email. * Verify that inbound email to apps works, by having you email it.
<kentonv>
paulproteus: sure, might need a new category though
<kentonv>
if websockets don't work you might have trouble getting to the app in the first place
<kentonv>
the app could maybe email itself to test that inbound email works
<kentonv>
inbound and outbound
xcombelle has joined #sandstorm
<paulproteus>
ooohhhh self-email, very nice idea
<kentonv>
I suppose there's some chance that someday it'll optimize away and therefore not actually test anything
<paulproteus>
I was going to say, yeah. (-:
<paulproteus>
That and/or the server has some configuration which basically equals that.
<paulproteus>
But yeah, doing that, but then asking the user to do something in their email client; seems like having both is non-crazy.
<zarvox>
dwrensha: I seem to be having issues with BrowserQuest in IE and Firefox - audio doesn't play, and when I click anywhere within the canvas, my character doesn't seem to move
<paulproteus>
Wow! I just helped a user!
<paulproteus>
This is pretty cool.
<neynah>
zarvox : now the BrowserQuest audio won't stop playing!