04:14:37synchronesince answering to that request requires launching the grain
04:16:06synchroneunless sandstorm dives into implementing even more WebDAV than it already does, making some DAV: capabilities configurable from capnp file
04:55:13kentonvsynchrone: what is it hoping to see in the OPTIONS request? "Dav: 1"?
04:58:43kentonvproposal #1: We always return DAV: 1 on unauthenticated OPTIONS requests.
05:00:02kentonvproposal #2: We extend API key creation (e.g. via offer templates) with the ability to specify certain OPTIONS headers that should be returned unauthenticated. We could even let you specify static responses to certain routes, which would solve mnutt__'s problem with ownCloud wanting to hit /status.php unauthenticated.
05:01:02kentonvin proposal #2, these responses would be specified statically at token creation time and would not require spinning up the app for unauthenticated requests.
05:03:30phildini+1 for unauthenticated API options. would unlock a bunch of interesting things.
05:03:59phildini(note that I meant options not OPTIONS, since I think there are legitimate uses for having un-authed endpoints in webapps)
05:18:04asheeshi,i "the problem is that static publishing is a singleton!"
05:25:23mnutt__asheesh: I had exactly the same thought the other day "I want to publish one of my shared sub-directories as a photo album. wait, that means I can only publish _one_ from the whole shared directory"
05:42:48synchroneand to asheesh's point about static publishing (not sure if it's even in the context of un-authed responses): token-based static responses would be not-so-static I guess
05:45:13asheeshIMHO to me, un-authed responses to the "API subdomain" sound to me like the "API subdomain" wants to delegate some of its actions to (effectively) static publishing.
05:46:09synchrone...we're trying to fit the unfittable in that authenticated-api-client-only world
05:46:50asheeshBTW, does anyone feel like testing Apache2 + Sandstorm web sockets reverse proxying?
05:52:56kentonvso if the host is going to serve anything app-specific without requiring a key, that stuff needs to be specified statically in advance at a time when the grain is running
05:53:45synchronehow much data could an app associate with the token?
05:54:09synchronelike, some people would probably like to "publish a single file" using that mechanism
05:54:59synchronecertainly would be nice to specify full blown route and response headers + body
05:55:01kentonvthe implementation I had in mind for solving the API problems would be designed for maybe a few hundred bytes of data, not for serving whole files.
05:55:12synchronewithout proxy.js getting up my app-specific business
05:55:23kentonvfor serving whole files or web sites, you want to use static web publishing
05:56:19synchronecompiling that C++ sucks though. I am already dreaming about reading that static publishing ID from a virtual file somewhere inside my grain
05:57:24kentonvcap'n proto bindings exist in several languages, and I'm also open to adding some sort of endpoint on sandstorm-http-bridge if you don't have Cap'n Proto bindings available.
06:04:12kentonvsynchrone: the current web publishing API is actually "put your site in /var/www, then make one RPC to Sandstorm to tell it that it's there and determine the hostname to display to the user"
06:09:46kentonvsynchrone: if I can serve arbitrary headers from a resource in your domain, I can brick your domain
06:10:27synchronewith some filtering the way XHR disallows you based on a blacklist?
06:10:30kentonvnamely, I can pin your domain certificate to something broken and now user's browsers will refuse to load your domain until the HSTS timeout
06:11:29kentonvmany features correspond to specific headers, but instead of expressing them in terms of HTTP headers, we have a Cap'n Proto structure which represents the content in a logical way
06:11:51synchronegenerally whitelisting is good, but won't we have a situation similar to UA whitelist?
06:12:10synchronei need a feature - i can't fit it in capnp - i end up here, bothering you :)
06:12:37kentonvthere are fewer protocol features than there are apps, so this is less of a problem
06:14:19kentonvin web-session.capnp we added a header whitelist thing where you could specify arbitrary header names but they'd be filtered to a whitelist... but it immediately introduced a security problem. In retrospect I think we probably shouldn't have added it.
06:14:31kentonvluckily the security problem currently isn't exploitable for other reasons
06:15:32kentonvspecifically, we applied the whitelist filter at proxy.js but not again in sandstorm-http-bridge, which means that if a malicious party is able to call the app's WebSession API directly (something we intend to allow eventually), they can inject arbitrary headers, which among other things would allow them to spoof user authentication.
06:16:16kentonvhad we instead written a struct which had a bunch of string fields corresponding to headers we wanted to pass through -- instead of a list of key-value pairs -- this wouldn't have happened.
06:18:45synchroneso the plan is to express every standardized header and it's potentially quite complex values as capnp structs?
06:21:55kentonvit turns out that quite a lot of HTTP headers are transport details, not content details. Almost all of them are irrelevant to WebSession.
06:22:15kentonvwhat's left is not too complicated. We have it mostly covered today.
06:22:33kentonvWe need to add range requests and better cache control at some point.
06:22:34synchronewhich makes sense for content transfer protocol right?
06:23:24kentonvah but for publishing, Sandstorm will take care of ranges
06:23:30kentonvthere's no need for the app to think about it
06:23:37kentonvbecause the app isn't serving the content in real-time
06:24:37kentonvfor static web publishing, even fewer parts of the HTTP protocol really matter. It's pretty bunch down to Content-Type, Content-Encoding, Content-Language, and then the bytes.
06:25:30synchronei doubt Accept-Language is your best choice of a mechanism
06:26:33kentonv(again, we're talking about static sites here, not dynamic UIs)
06:27:43synchroneand then some user with ru-RU, en-US, ua-RU, en in his browser will come with a link he got after switching the app to Ukranian and see the russian text
06:30:38synchroneI mean the HTTP's original Accept-Language idea is awesome, but switching languages via cookies always overrules that
06:31:02asheeshFWIW, Sandstorm could pseudo-standize that perhaps (-:
06:31:22synchronegod, so many websites doing an awful job at language selection
06:31:39synchronei am a russian, in germany, with browser prioritized to english
06:31:45asheeshThe app could use JS to set a cookie called 'pseudo-accept-language: en-US' and then Sandstorm static publishing could treat that as overriding the Accept-Language header.
06:31:53synchronei've seen some stuff in 3 langs at the same page... e.g in Google play store
07:51:37mrdominokentonv: just invited you. i got a report from another invitee that a not-expected email from their github was used, that they don't normally use
07:55:04kentonvdwrensha: github tells us which address is "primary". We should really respect that. Maybe it's as easy as re-ordering the address to be first?
11:14:43mnutt__I don't _think_ it would hurt anything to have sandstorm unauthenticated OPTIONS send Dav: 1 header always, but I'd be willing to test it.
14:53:13ocdtrekkieSo, if I have an old Sandstorm local install I used for all my dev'ing of things, and I tried updating an app on it, and it no longer runs. (The app runs correctly still outside Sandstorm, and the grain does load most of the way in Sandstorm, it just can't load the saved sqlite data, I'm guessing.)
15:18:21ocdtrekkieI took my previous version app code, and it does the same thing now.
17:37:53synchronemnutt__: except iOS would be complaining about Ca(rd|l)DAV address being invalid
17:38:45synchroneit would of course work, but the user would have to insist on saving that configuration
17:40:22synchrone..which is a bad UX. Even worse than having to somehow copy the url and token to device (potentially giving them up to Apple\Google via email or some IM in the process of sending to one's self), since there's no way a human being can type all those chars
23:08:25canukyMongoDB question ... I have a few handles in my admin/users table that I don't recognize and I would like to look them up ... correct query is- db.users.find({"profile.handle": <handle>}) ?
23:19:19dwrenshacanuky: that should work, unless the handles aren't filled in yet
23:19:57dwrensha(the field get filled in when the user confirms their profile on first login)
23:20:39canukyAh ha ... I have a few people listed as 'Guest' that used passwordless email login .. hoping to find their email so I can reach out to them
23:21:54canukyhandle is listed in the table, just not sure how to find their associate email domain
23:22:20canukylisted in the user/admin dashboard table, that is
23:22:39juicefI wonder about the Ghost app. It seems like it's been abandoned since it's lags several major app updates behind. Is there an idea of how much update lag there's gonna be with Ghost specifically, or apps in general?
23:25:31dwrenshajuicef: Agreed that the Ghost app could use some love.
23:26:42dwrenshajuicef: the big blocker is that upstream redid their authentication logic a while back
23:27:53dwrensha... so there are some major changes to be made in the Sandstorm port, and jparyani hasn't had time to figure them out.
23:29:54dwrenshajuicef: the ideal is that upstream authors will be responsible for maintaining their Sandstorm packages
23:30:18dwrenshathis is already the case for rocket.chat, wekan, and ethercalc
23:39:20juicefdwrensha: I agree, I reckoned that was the thought up ideal solution. How's the Ghost team on this issue? Resource scarcity or competing business logic interfering perhaps?
23:41:42dwrenshaI don't know whether we have ever contacted the Ghost upstream people.
23:52:46juicefdwrensha: I feel that for certain apps with their own infrastructure up and running (WP and WP.com) (Ghost and Ghost.org) an extra effort is going to be needed to have those apps freshly available on SS.
23:53:47juicefSeems now that the smallest, less known apps are the perfect fit for SS. But alot of people need the big ones as well.