<mnutt_>
I just tried to generate a webkey via the sandstorm webkey icon and ended up generating a key that looks like: undefined#x-Ux-dU2XZPAHgHwO851GLYF4zd2Zdxi_BpVXhuUU9G
<mnutt_>
(I'm on sandstorm 0.146)
<kentonv>
mnutt_: yeah I broke it
<kentonv>
:(
<kentonv>
fix is submitted but I'm not sure if enough people actually use this interface to do an early release
<mnutt_>
ah, no worries
<kentonv>
FWIW you can substitute api.whatever.sandcats.io manually and it works
<kentonv>
(or api.oasis.sandstorm.io, etc.)
<digitalcircuit>
Out of curiosity, what's the usual release schedule? Weekly? Feature-based?
bodisiw has joined #sandstorm
<kentonv>
mnutt_: what were you testing, out of curiosity
<kentonv>
mnutt_: or rather, doing
<mnutt_>
I was going to try to see if I could get Radicale working with iOS's built-in contacts management
<kentonv>
mnutt_: ah, there is a cloud button on the radicale sidebar which brings up an offer template
<kentonv>
digitalcircuit: Lately I've been trying to do them on Saturday or Sunday evening. Oasis still doesn't have rolling updates so if I'm going to take the service down for a couple minutes I want to do it at low tide.
<mnutt_>
sadly, it's just for calendar
<kentonv>
mnutt_: oh, I see
<digitalcircuit>
kentonv: Makes sense! Still avoids most of the risks of a start-of-weekend release, too.
<kentonv>
digitalcircuit: yeah those risks are usually something like "people might not be around to address problems", but I'm definitely here to fix problems on weekends. :)
phildini_ is now known as phildini
* digitalcircuit
nods
<digitalcircuit>
Though not having to fix problems on the weekends may eventually be nice, too :)
<kentonv>
some day!
mnutt_ has quit [Ping timeout: 240 seconds]
dvn has joined #sandstorm
mnutt_ has joined #sandstorm
synchrone has quit [Ping timeout: 248 seconds]
amyers has quit [Remote host closed the connection]
amyers has joined #sandstorm
amyers has quit [Remote host closed the connection]
<zarvox>
HTML5 at least specifies precisely how the parser is supposed to deal with invalid documents (well, the WHATWG spec does, I forget if the W3C document covers it)
<synchrone>
let's see if that Radicale 1.1.1+v7 gets everything fixed :)
<synchrone>
v6 was packaged incorrectly, I had a dirty working tree
<synchrone>
(iOS still misbehaves on setting up the URL, but seems to work if you insist)
joshbuddy has joined #sandstorm
synchrone has quit [Ping timeout: 248 seconds]
jacksingleton has quit [Ping timeout: 244 seconds]
jacksingleton has joined #sandstorm
synchrone has joined #sandstorm
eglimi has joined #sandstorm
asmyers has joined #sandstorm
amyers has quit [Ping timeout: 240 seconds]
bb010g has quit [Quit: Connection closed for inactivity]
jadewang has joined #sandstorm
eglimi has quit [Ping timeout: 276 seconds]
tdfischer has quit [Ping timeout: 255 seconds]
eglimi has joined #sandstorm
tdfischer has joined #sandstorm
<synchrone>
damn iOS
<synchrone>
in the end it turned out to do unauthenticated OPTIONS request to the calendar url
<synchrone>
which is pretty much a deal breaker
<synchrone>
since answering to that request requires launching the grain
<synchrone>
unless sandstorm dives into implementing even more WebDAV than it already does, making some DAV: capabilities configurable from capnp file
<asheesh>
oh fascinating
<asheesh>
cc: @kentonv
jadewang has quit [Remote host closed the connection]
sydney_untangle has quit [Ping timeout: 264 seconds]
<kentonv>
synchrone: what is it hoping to see in the OPTIONS request? "Dav: 1"?
tuckerm has joined #sandstorm
faitswulff has joined #sandstorm
<kentonv>
proposal #1: We always return DAV: 1 on unauthenticated OPTIONS requests.
<kentonv>
proposal #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.
<kentonv>
in proposal #2, these responses would be specified statically at token creation time and would not require spinning up the app for unauthenticated requests.
<kentonv>
synchrone: thoughts?
<phildini>
+1 for unauthenticated API options. would unlock a bunch of interesting things.
<phildini>
(note that I meant options not OPTIONS, since I think there are legitimate uses for having un-authed endpoints in webapps)
mnutt__ has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
mnutt__ has joined #sandstorm
<mnutt__>
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"
sydney_untangle has quit [Remote host closed the connection]
<mnutt__>
I later decided that meant I should be splitting up my grains more, though I have a vague wish for better grain management
<zarvox>
agreed on the "better grain management" - I'm curious to know which low-hanging fruit would be the most valuable for you
<zarvox>
for me it'd probably be "(batch) deletion from the grain list"
<synchrone>
kentonv: №2 seems to let more apps in
<synchrone>
and 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
eglimi has quit [Ping timeout: 240 seconds]
<asheesh>
IMHO 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.
<synchrone>
...we're trying to fit the unfittable in that authenticated-api-client-only world
<asheesh>
BTW, does anyone feel like testing Apache2 + Sandstorm web sockets reverse proxying?
<asheesh>
...Maybe I will ask a friend elsewhere, too.
<synchrone>
maybe subdomain could be used for grain routing, enabled for anonymous requests only?
* synchrone
tries to relax them security-minded rules :)
<kentonv>
no, to start up the grain you need to have a key. This will become a hard rule when we have fine-grained encryption.
<kentonv>
a hostname is not a key.
<kentonv>
only the token is
<kentonv>
so 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
<synchrone>
how much data could an app associate with the token?
<synchrone>
like, some people would probably like to "publish a single file" using that mechanism
<synchrone>
not just plug a weird client, like i do
<synchrone>
certainly would be nice to specify full blown route and response headers + body
<kentonv>
the 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.
<synchrone>
without proxy.js getting up my app-specific business
<kentonv>
for serving whole files or web sites, you want to use static web publishing
<synchrone>
compiling that C++ sucks though. I am already dreaming about reading that static publishing ID from a virtual file somewhere inside my grain
<kentonv>
cap'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.
<kentonv>
synchrone: 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"
<kentonv>
synchrone: if I can serve arbitrary headers from a resource in your domain, I can brick your domain
<synchrone>
with some filtering the way XHR disallows you based on a blacklist?
<kentonv>
namely, I can pin your domain certificate to something broken and now user's browsers will refuse to load your domain until the HSTS timeout
<kentonv>
that's basically what we do
<kentonv>
we expose specific features
<synchrone>
I see a whitelist there
<kentonv>
many 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
<synchrone>
generally whitelisting is good, but won't we have a situation similar to UA whitelist?
<synchrone>
i need a feature - i can't fit it in capnp - i end up here, bothering you :)
<kentonv>
there are fewer protocol features than there are apps, so this is less of a problem
<kentonv>
in 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.
<kentonv>
luckily the security problem currently isn't exploitable for other reasons
<kentonv>
specifically, 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.
<kentonv>
had 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.
<synchrone>
so the plan is to express every standardized header and it's potentially quite complex values as capnp structs?
sydney_untangle has joined #sandstorm
<kentonv>
synchrone: yes
<synchrone>
ambitious. I like it :)
<kentonv>
it turns out that quite a lot of HTTP headers are transport details, not content details. Almost all of them are irrelevant to WebSession.
jadewang has joined #sandstorm
<kentonv>
what's left is not too complicated. We have it mostly covered today.
asmyers has quit [Ping timeout: 240 seconds]
<kentonv>
We need to add range requests and better cache control at some point.
<synchrone>
which makes sense for content transfer protocol right?
<synchrone>
range totally makes sense for publishing
<kentonv>
yeah
<kentonv>
ah but for publishing, Sandstorm will take care of ranges
<kentonv>
there's no need for the app to think about it
<kentonv>
because the app isn't serving the content in real-time
<kentonv>
for 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.
sydney_untangle has quit [Ping timeout: 244 seconds]
<synchrone>
i doubt Accept-Language is your best choice of a mechanism
<synchrone>
that needs to be left for the app
<kentonv>
sure but what the app will do is place different lanugages at different paths
<kentonv>
presumably
<kentonv>
(again, we're talking about static sites here, not dynamic UIs)
<synchrone>
and 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
<synchrone>
because the first language matches better
<synchrone>
and he was just using russian OS\browser for whatever reason
<synchrone>
so the app will need to control which entity links it serves
<synchrone>
which ends up in /<alpha2> in your urls
<synchrone>
I mean the HTTP's original Accept-Language idea is awesome, but switching languages via cookies always overrules that
<asheesh>
FWIW, Sandstorm could pseudo-standize that perhaps (-:
<synchrone>
god, so many websites doing an awful job at language selection
<synchrone>
i am a russian, in germany, with browser prioritized to english
<asheesh>
The 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.
<synchrone>
i've seen some stuff in 3 langs at the same page... e.g in Google play store
<asheesh>
: D
<asheesh>
I "look forward" to us adding i18n to Sandstorm instelf.
<synchrone>
gon' be hard
<synchrone>
:D
<synchrone>
usually people understand all the languages the poor software detects for them
<synchrone>
..but I don't know German, for example
<synchrone>
some websites abuse GeoIP too much
<synchrone>
the ads are the worst
<synchrone>
ok, getting back to my original topic: I need static unauthenticated endpoints in my API
<synchrone>
what do I do/
<kentonv>
what specifically does the OPTIONS request need to return?
<kentonv>
in your case
<dwrensha>
i,i what if instead of AdBlock, we had AdGreek?
<synchrone>
in my case OPTIONS response body is empty
<synchrone>
so just the headers, namely DAV:
<synchrone>
this is what iOS wants to see
<kentonv>
is there any important header other than DAV:?
<synchrone>
not in this case
<kentonv>
ok, cool
xet7 has joined #sandstorm
raoulzecat has quit [Ping timeout: 244 seconds]
rustyrazorblade has joined #sandstorm
xet7 has quit [Quit: Leaving]
sydney_untangle has joined #sandstorm
frigginglorious has quit [Ping timeout: 240 seconds]
sydney_untangle has quit [Ping timeout: 240 seconds]
wolcen has quit [Ping timeout: 250 seconds]
synchrone has quit [Quit: Leaving.]
synchrone has joined #sandstorm
neynah has joined #sandstorm
synchrone has quit [Ping timeout: 255 seconds]
XgF has quit [Quit: No Ping reply in 180 seconds.]
<mrdomino>
kentonv: 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
<mrdomino>
(to c.wholezero.org that is)
<kentonv>
mrdomino: yeah we need to select email addresses better
<mrdomino>
ok cool, that's known
<kentonv>
dwrensha: 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?