<au>
"Your submission is approved and is currently live!" it says
<au>
I wonder if it's because of the "cpal" change I made locally?
<kentonv>
I don't think so; I updated the index app for that.
<au>
ok. last time it said "a human being will look into it" (or something equivalent)
<au>
and this time it says it's approved
<kentonv>
right. It seems like it's in the correct state, but it's not showing up for some reason. I think the indexer must have disliked it but it's supposed to log an error and it didn't.
<au>
OK. well you have all the information that I have...
<au>
so let me know if I can help in some way; I'll be off-net soon for 12 hours on a plane from Taipei to Paris
<kentonv>
ok, yeah, it seems like a bug on my end so I'll investigate
<au>
\o/ good luck on the appstore launch!
<kentonv>
bah, it's totally published in the index, but the front-end is choking.
<au>
the indexer rejected "Collaborative Spreadsheet" because it's 25 letters, I changed it to "Multi-user Spreadsheet" and it seems to like it
<au>
(the error message on that was pretty helpful)
<kentonv>
heh... well, that's a heuristic, it still could be too long. We'll see once I get it to display at all.
<kentonv>
ohhhhh
<au>
"Web Spreadsheet" is fine if it's too long
<au>
mm?
<kentonv>
it's because you have no name set on Keybase
<au>
ah. easily remedied
<kentonv>
indeed. I'll have to check for that more carefully in the future.
<kentonv>
interesting that the effect is it just rejected the whole listing outright... validating input a little too well, I guess
<tomreyn>
dwrensha: no, not at the main page, but yes, on this (demop.sandstorm.io) sandstorm installation. it's on the (now expired) demo 'account' / session the Grain I posted in the pastebin refers to.
<tomreyn>
put simply: it is my current understanding that it's currently impossible to run any demo at https://demo.sandstorm.io/
<tomreyn>
where "run" refers to actually using an installed web application.
<dwrensha>
eek
<dwrensha>
tomreyn: which browser are you using?
<tomreyn>
firefox 40.0.3, with some extensions and non-default settings.
<tomreyn>
i could try chromium or a new firefox profile if it help.
<dwrensha>
heh, yeah, it fails for me on Firefox 40.0 also
<dwrensha>
but it seems to work on Chrome
<dwrensha>
that's odd
<tomreyn>
not at all, mozilla / firefox tends to have a different approach to hardening things than google / chromium.
<tomreyn>
i bet the browser console would explain what the issue is.
<dwrensha>
Looks relevant: "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://demo-ddp.sandstorm.io/sockjs/605/36yd5ht9/xhr. (Reason: CORS header 'Access-Control-Allow-Origin' missing).'
<tomreyn>
one issue (probably unrelated) i noticed is that applications are installed from a HTTP (not HTTPS) URL
<dwrensha>
that shouldn't be a problem
<dwrensha>
(note that they are verified against a SHA-256 hash of their content)
<tomreyn>
well it is likely a security problem, but it is surely unrelated to this issue we are discussing.
<tomreyn>
ah so no security issue then
<tomreyn>
(that's if those hashes are delivere through a different and secure channel)
<tomreyn>
my understanding is that demo.sandstorm.io is a demo instance / installation of the sandstorm software, and that https://sandstorm.io/apps/ is a central application store which a sandstorm installation may retrieve apps from.
<dwrensha>
yes, that is accurate
<dwrensha>
https://sandstorm.io/apps/ hosts links of the form /install/f0c18bb97e5f0aa76dc2e709a3b0b449?url=http://ethercalc.net/ethercalc-201505183.spk
<tomreyn>
usually the central application store would have information on which applications are available for installation, and ideally they would have undergone some kind of security review, which then sandbox installations could benefit from by trusting it.
<dwrensha>
which means that "the app with content f0c18bb97e5f0aa76dc2e709a3b0b449 has been approved for the central app list"
<dwrensha>
then when you install the app, your server will verify that the actual spk you receive matches the hash
<tomreyn>
what i do not understand is how the sandstorm demo installation is retriveing the secure application hash from the app store
<tomreyn>
but we can just ignore this topic for now, i probably just need to read up and test more
<tomreyn>
i'm more interested in fixing the CORS issue for now.
<dwrensha>
huh
<tomreyn>
whouls you know what DDP in demo-ddp.sandstorm.io stands for and whether the javascript is intentionally sourced from a different domain than the rest of the demo web application?
<dwrensha>
I think the javascript is cached using CloudFlare
<dwrensha>
Now in Firefox the only error I'm seeing is "This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1."
<tomreyn>
thanks. trying with a new firefox profile now.
<tomreyn>
works
<dwrensha>
\o/
<dwrensha>
I think this second error you hit is a Firefox bug.
<dwrensha>
Unsure about the CORS thing.
<tomreyn>
14:58:50.696 SyntaxError: unreachable code after return statement1 19b26b7acc1dd93c7a998c4fd87c2d209960d057.js:41:30998
<dwrensha>
The CORS error seems like either a misconfiguration of demo.sandstorm.io, or a CloudFlare problme
<tomreyn>
could be, hard to tell
<tomreyn>
14:58:41.871 The connection to wss://demo-ddp.sandstorm.io/sockjs/546/clu2fmiv/websocket was interrupted while the page was loading. 19b26b7acc1dd93c7a998c4fd87c2d209960d057.js:68:0
<tomreyn>
maybe cloudflare doesn't support WSS?
<tomreyn>
or websockets in general
<tomreyn>
since that's not standard http traffic
<dwrensha>
I'm not too familiar is how things are configured with CloudFlare. Maybe kentonv will be able to do some diagnosis when we wakes up.
<mquandalle>
I'm using a keybase account (mquandalle)
<mquandalle>
So I've used the following commands:
<mquandalle>
echo -n "I am the author of the Sandstorm.io app with the following ID: m86q05rdvj14yvn78ghaxynqz7u2svw6rnttptxx49g1785cdv1h" | keybase sign -b > pgp-signature
<tomreyn>
also more connection resets to wss://demo-ddp.sandstorm.io/sockjs/767/3kbw6hvt/websocket
mort___ has left #sandstorm [#sandstorm]
<tomreyn>
i assume it can be since with my default firefox profile (and thus the "noscript" extension, with demo.sandstorm.io whitelisted) i'm stuck at the spinning wheel again
<tomreyn>
okay works after reloading the page
<dwrensha>
mquandalle: it looks like `keybase sign` does not do the same thing as `gpg --sign`
<dwrensha>
I'm not sure what `keybase sign` does.
<mquandalle>
hmm, for some reason I wasn't able to unlock my passphrase protected key with gpg --sign
<dwrensha>
If you do it correctly, `cat mquandalle-pgp-sig | gpg` should print out the statement that you signed.
<dwrensha>
maybe keybase has a separate notion of passphrase, that's distinct from you gpg passphase?
<mquandalle>
You're right that doesn't work
<mquandalle>
That's was an issue with gpg-agent, disabling it forced gpg to ask for my keybase passphrase (I never used this stuff before)
<dwrensha>
mquandalle: so did you get it to work?
<mquandalle>
`cat mquandalle-pgp-sig | gpg` works, will publish in ~20min
<dwrensha>
cool!
<mquandalle>
Done, thank you for the help dwrensha :-)
bb010g has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 250 seconds]
mnutt__ has joined #sandstorm
simonv3 has joined #sandstorm
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 265 seconds]
mnutt__ has quit [Quit: mnutt__]
ripdog has quit [Ping timeout: 256 seconds]
ripdog has joined #sandstorm
mnutt__ has joined #sandstorm
gopar has joined #sandstorm
bb010g has quit [Quit: Connection closed for inactivity]
mnutt__ has quit [Quit: mnutt__]
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 244 seconds]
itscassa|away has quit [Ping timeout: 250 seconds]
itscassa|away has joined #sandstorm
mnutt__ has joined #sandstorm
jadewang has joined #sandstorm
<kentonv>
mquandalle: Yay, wekan is now up!
jadewang has quit [Ping timeout: 255 seconds]
mnutt__ has quit [Quit: mnutt__]
<kentonv>
tomreyn: the package hash is passed in the install URL, i.e. by your browser, over HTTPS.
<kentonv>
dwrensha, tomreyn: the DDP host is not behind cloudflare (this is exactly why it's a separate host). It ought to be setting access-control-allow-origin correctly, so that's weird.
mnutt__ has joined #sandstorm
<mquandalle>
Cool :-)
<mquandalle>
Hmm, I'm seeing a weird bug upgrading one of my Libreboard instance to Wekan (others works without problems)
<kentonv>
?
<mquandalle>
It seems to be a meteor issue related to multiple keys in the `meteor_accounts_loginServiceConfiguration` collection
<mquandalle>
Did you already see something like that?
<mquandalle>
(That's strange because I don't think I use this collection...)
<kentonv>
yeah that should only apply if you have oauth accounts enabled, which under sandstorm you shouldn't...
<mquandalle>
Downloaded the grain, will try to read the monogd database from it
<mquandalle>
Here is the error: http://pastebin.com/raw.php?i=MvVn1xL6 (I don't ask anyone to do my debugging homework, just curious if anyone have already experienced this in the context of meteor+sandstorm ;-))
mnutt__ has quit [Quit: mnutt__]
<kentonv>
that pastebin just tells me "Please refresh the page to continue..."
xcombelle has quit [Remote host closed the connection]
<kentonv>
hmm, the underlying "too many namespaces/collections" error is worrying
<kentonv>
it seems like the problem actually isn't a key uniqueness thing, but rather that
<mquandalle>
Yep that's the real problem
<mquandalle>
the meteor_accounts_loginServiceConfiguration thing is a false alarm
<mquandalle>
(I checked the collection don't even exist in the grain data)
<kentonv>
do you dynamically create new collection names?
<mquandalle>
No I don't think so
<mquandalle>
But that may be related to GridFS
<mquandalle>
And maybe GridFS create new collections?
<mnutt__>
are there any heuristics we can use to determine if a URL is a webkey? right now I’m thinking just 1) URL has a fragment, and 2) URL has no path. Which is probably sufficient for my purposes but if I could lock it down a bit further (perhaps on the fragment length) that would be good. I’m working on having a client detect that it has been passed a sandstorm webkey.
<mquandalle>
This instance wasn't particularly large but had a few image on it (~5)
simonv3 has quit [Quit: Connection closed for inactivity]
<kentonv>
mquandalle: hmmmmm, maybe.
<kentonv>
I wonder if Mongo is upset about niscu allocating small files. :/
<kentonv>
mnutt__: Usually we go with "has a fragment" as the heuristic
<kentonv>
since these client apps normally don't expect a fragment
<mnutt__>
kentonv: yeah, I think that works in this case too, I can’t imagine another scenario where a fragment would be present in the server URL
<mquandalle>
niscu?
gopar has left #sandstorm ["Leaving"]
<mquandalle>
Another question: In capnp files does the "embed" function (or directive, or whatever it is called) works with UTF-8 chars?
<mquandalle>
I was able to reproduce the mongoDB error
<mquandalle>
Recipe: take the libreboard v0.8 spk, start a grain, create some cards and upload ~7 pictures (or more generally "files" I guess), upgrade the grain to wekan v0.9 → doesn't work.
<mquandalle>
Maybe storing files in mongodb is too crazy
<mquandalle>
But that was convenient for me because Wekan supports sandstorm, and docker, and manual install, and the file system permissions would be different in these different environments.
jadewang has joined #sandstorm
jadewang has quit [Ping timeout: 268 seconds]
<dwrensha>
mquandalle: looks like the description encoding problem is that apps.sandstorm.io is rendering the description as Latin-1
<kentonv>
I'm going to fix that
<kentonv>
on the app market the problem is the index is downloaded as a JSON blob which apparently doesn't get the right charset
<kentonv>
in capnp, all text is UTF-8 always period.
<kentonv>
but on the web, all text is LATIN-1 unless stated otherwise. :(
<kentonv>
mquandalle: it's definitely worrying if it's that easy to break mongo under sandstorm
<kentonv>
"niscu" is our fork of mongo that avoids pre-allocating so much disk space
<kentonv>
meteor-spk uses it automatically
<kentonv>
but maybe by forcing small files we inadvertently made Mongo break down in certain situations where it really shouldn't?
<kentonv>
I have to reboot now; hopefully it will make Chrome stop saying "waiting for available socket" and taking 5 minutes to load a page from localhost
<dwrensha>
mquandalle: how do I upload a picture to Wekan?
kentonv has quit [Quit: Leaving]
<mquandalle>
dwrensha: open a card, click the menu icon (uper-right, next to the close icon) and click "attachments"
<mquandalle>
(The UI still need some work, but it's better to release something)
<dwrensha>
mquandalle: I'm getting the "too many namespaces/collections" error with no migrations required
<mquandalle>
yep, reproduced
<mquandalle>
so that's an issue with v0.9 that v0.8 didn't have
kentonv has joined #sandstorm
<mquandalle>
One difference could be that this time I builded meteor-spk myself
<mquandalle>
I didn't change the code related to attachments, but I rely on collection-fs and it's totally possible that they changed something
<dwrensha>
"error: hashtable namespace index max chain reached:5"
<dwrensha>
^ in Wekan logs
<mquandalle>
I don't see that, any clue what that mean?
<dwrensha>
I see it in a file called "mongo.log.2015-08-30T21-04-07"
<dwrensha>
If I google for that error, I see that the usual value is 1335, not 5
<dwrensha>
the `maxChain` value is proportional to a `bufLen` value