I am having lots of trouble with this :/
See my test work on gh-pages (careful, it's live so only /auth/dropbox/oauth2/ can be modified) and dropbox-oauth2
Apparently, the parent receives the message, and dispatches one of its own that the child does not receive
This is my modification to {dropboxjs}/src/auth_driver/browser.coffee
Any ideas?
(P.S. when we get it working I think we could move it to our own "driver" so we are not required to patch dropbox.js with every update)
In case you haven't caught that yet, my first guess would be on line 487 you
addEventListener receiveMessage, which is only defined on line 488
This message was deleted
lol, that was it :D
Cool :+1:
So, file has a
null origin so I can't allow it
Oh, that's a shame
One thing about the building thing: with HTTPS/2 it might not be faster anymore to make less requests
I'm still going to create something for now though
When is that coming?
:+1: sounds good. It will be smaller at least!
HTTP/2 I mean. It's already here, e.g. here is an implementation for Node JS: https://www.npmjs.com/package/http2. Etcetera
It depend on your server stack whether or not it's easy to start using it I guess
We just use github pages atm
So, are you working on the build stuff?
It works!!!
joshua-s @joshua-s sets topic to error
Sometime within the last few days, we did something that causes NS_ERROR_FILE_NOT_FOUND: when trying to load modules/editor/editor.html
The error occurs on develop and dropbox-oauth2
The cause: #304
I have added a comment
Fixed!
Uhm, is it used there or just referenced?
Oh, it's just referenced
Removed!
@twiss I think we can merge #299 now!
Er, aren't you supposed to use an actual domain that we own in
origin?
You could just submit it and see if they complain
You mean as the app's origin
Yes, like
app://firetext.codexa.bugs3.com or something, I don't know
Or the github one
Maybe they'll find
app://firetext is just fine though, and it's certainly cleaner
Yeah. I'm asking, but I think they won't mind
I think the principal is to not have apps specifying things like app://facebook.com as their origin
Yes
There might be some sort of verification process though, so I'm going to test it right now
Also, not that it looks like it matters much but why did you change the regexes?
And, do you have the latest browser.coffee somewhere or didn't it change beyond that bugfix?
I changed the regexs to detect an origin as opposed to returning one
So, all localhost origins return the string "localhost"
All file:// origins (if they weren't null) would return "file"
And the other regexs were not changed
Oh, I'm comparing to a different browser.coffee then I think
I moved all my changes into
scripts/cloud/dropbox_authdriver_firefoxos.js
So,
dropbox.min.js is the vanilla build with no changes from their repo
Right, cool
Oh, I'll fix that bug
Nasty coffeescript compile error
Also,
e.origin already contains an origin, not a location. It's not important, but you could remove the last regex probably
We could, except I have it there for the localhost and file:// cases
(where what we check is not a standard origin, but compliance with a scheme)
Yup
So, we don't have to add every localhost scheme and port to the whitelist
I messaged someone on Mozilla's IRC channel, and he said the origin should be fine
Cool
...as long as we don't use something like
app://facebook.com
So, did you say it works from
file:// now?
Everything but dropbox (null origin)
Alright. Well you could remove it but it doesn't matter. Looks ready to merge to me!
Remove file from the whitelist?
Yes, and the regex check. The only regex check you then need is the one for localhost
That sounds good :)
That is only in the server code, so we can merge
dropbox-oauth2 and modify server whenever
Yup
Alright, then!
Cool! Gratz and thanks for the hard work :)
No problem, thanks for preventing me from shipping insecure stuff :D
Always! :)
So, about
So, are you working on the build stuff?
I started working on it yes, the current idea is a giant hack and will produce a single html file with scripts and css inlined
Cool!
There's much to be improved on that probably, but this was the easiest thing that came to mind
One thing: inline css/js are blocked by CSP
Well, it won't be faster for Firefox OS anyway
Since it doesn't have a maximum amount of concurrent requests
tbh I'm not even sure if it will be faster on a server
That's ok. It will be concise and minified, right?
Well, if you do that part it will be :)
Nah, I'll see if it's easy to do
What are you using? I have heard many good things about node
As server stack?
As the build system
I'm using node yes, and a two line shell script. There are probably more organized ways to do it esp when/if you want it to work on Windows
:+1:
Do you want to get the build in by this release or wait until next?
Well, I don't think it matters much for FFOS either way, but let me finish a PR, it shouldn't take long