875991 - Update and Include X-Ray Goggles as a node app for inclusion in the webmaker.org suite

Status: RESOLVED FIXED

(Webmaker Graveyard :: X-Ray Goggles, defect)

Description

[David Humphrey (:humph)]

This is a meta-bug for the work related to updating and including X-Ray Goggles to work in the new Webmaker.org.

NOTE: this work won't be starting until after June 15.

Comment 1

[Pomax]

I have the initial version of this up on https://github.com/pomax/xray-on-node, which basically uses the webxray submodule as part content, part data resource. The node app compiles webxray.js on startup by doing virtually the same thing as the real "go.py compile" command does, but without needing python. So the stub works - you can X-rayify, create the bookmarklet button and have it work, and in theory you can publish to any hackpub API compatible endpoint we want. Like Thimble's endpoint, or perhaps its own.

Comment 2

[Pomax]

A test version of this is now up on http://limitless-everglades-5263.herokuapp.com -- however, there are some SSO issues.

For testing, there are two heroku help instances:
- webmaker.org on http://quiet-fortress-6677.herokuapp.com
- login.webmaker.org on http://obscure-fjord-5429.herokuapp.com

For some reason, CSRF errors are preventing SSO from working for new users, with the login's new_user.html going "you cannot actually use me" when the goggles app asks for it (the ALLOWED_DOMAINS for the login.wm.o instance include all three heroku app domains)

Additionally, when testing SSO on the webmaker.org helper instance, the new_user form does show up, but filling in any name leads to "Another user has already claimed ...", despite this not actually being the case.

I'm fairly confused what's going on, perhaps some other people have ideas?

Comment 3

[Pomax]

added needinfo for jbuck, sedge and mjschranz, in the hopes of figuring out why this is not working.

Both login and webmaker are on current-as-of-this-comment master, and the env. variables are as follows:

[goggles.webmaker.org]

AUDIENCE:            http://quiet-fortress-6677.herokuapp.com
BUGREPORTHACKPUBURL: http://limitless-everglades-5263.herokuapp.com/
HACKPUBURL:          http://limitless-everglades-5263.herokuapp.com/
HOSTNAME:            http://limitless-everglades-5263.herokuapp.com/
LOGIN:               http://obscure-fjord-5429.herokuapp.com
LOGINAPI:            http://testuser:[e-mail]
PATH:                bin:node_modules/.bin:/usr/local/bin:/usr/bin:/bin
SESSION_SECRET:      I do enjoy a good cup of tea

[login.webmaker.org]

ALLOWED_DOMAINS: http://calm-headland-1764.herokuapp.com http://obscure-fjord-5429.herokuapp.com http://quiet-fortress-6677.herokuapp.com http://limitless-everglades-5263.herokuapp.com
ALLOWED_USERS:   testuser:password
AUDIENCE:        http://quiet-fortress-6677.herokuapp.com
COOKIE_DOMAIN:   .herokuapp.com
HOSTNAME:        http://obscure-fjord-5429.herokuapp.com
LOGIN:           http://obscure-fjord-5429.herokuapp.com
LOGINAPI:        http://testuser:[e-mail]
MONGOHQ_URL:     mongodb://[...omitted...]
MONGO_URL:       mongodb://[...omitted...]
PATH:            bin:node_modules/.bin:/usr/local/bin:/usr/bin:/bin
PORT:            80
SESSION_SECRET:  like strong Earl Grey

[webmaker.org]

AUDIENCE:       http://quiet-fortress-6677.herokuapp.com
DB_DIALECT:     sqlite
DB_STORAGE:     webmaker.sqlite
HOSTNAME:       http://quiet-fortress-6677.herokuapp.com
LOGIN:          http://obscure-fjord-5429.herokuapp.com
LOGINAPI:       http://testuser:[e-mail]
MAKE_AUTH:      testuser:password
MAKE_ENDPOINT:  https://makeapi.mofostaging.net
PATH:           bin:node_modules/.bin:/usr/local/bin:/usr/bin:/bin
PORT:           80
S3_BUCKET:
S3_KEY:
S3_SECRET:
SESSION_SECRET: Or some nice genmaicha

Comment 4

[Matthew Schranz [:mjschranz]]

So, thusfar seems like somehow it's managed to get a new account created with null _id, email and username! D:

Comment 5

[Pomax]

database wiping seems to have solved the secondary issue of not being able to claim a name on the webmaker.o or login.wm.o instances.

Original issue persists, relating to CSRF:

* Failed to load resource: the server responded with a status of 404 (Not Found) http://obscure-fjord-5429.herokuapp.com/ajax/forms/new_user.html
* Failed to load resource: Request header field X-CSRF-Token is not allowed by Access-Control-Allow-Headers. http://obscure-fjord-5429.herokuapp.com/ajax/forms/new_user.html
* XMLHttpRequest cannot load http://obscure-fjord-5429.herokuapp.com/ajax/forms/new_user.html. Request header field X-CSRF-Token is not allowed by Access-Control-Allow-Headers. myprojects:1
* Failed to load resource: the server responded with a status of 500 (Internal Server Error) http://limitless-everglades-5263.herokuapp.com/persona/verify

Comment 6

[Pomax]

repo changed location - new location is https://github.com/Pomax/goggles.webmaker.org

Comment 7

[Pomax]

Further investigation reveals the culprit is this line in the loginapi: https://github.com/mozilla/node-webmaker-loginapi/blob/master/index.js#L130

This throws a 500 error, with the response:

{
  "status": "failure",
  "reason": "User not found for ID: [e-mail]",
  "email": "[e-mail]"
}

Clearly, this is not a 500, but actually a 404 -- turning this 500 into 404 fixes it, but this needs to be done with a bit of care. Un-need-info'ing mjschranz and jbuck, but keeping sedge: we'll need to figure out what to do here.

Comment 8

[Matthew Schranz [:mjschranz]]

Hmm. Maybe something has changed yet again in the Login server?

I originally encountered this and fixed it here https://github.com/mozilla/node-webmaker-loginapi/commit/4b761200bbcd4f990f6ce5650cce4650974b250a

Can you explain how exactly this is being avoided?

Comment 9

[Pomax]

I'm not quite sure I understand the question; how what is being avoided? How the other apps work fine with the same code?

Comment 10

[Matthew Schranz [:mjschranz]]

The particular code I was combating with when I landed that change in the loginapi module was this https://github.com/mozilla/login.webmaker.org/blob/master/app/http/controllers/user.js#L36-L39.

It throws a 404 status code, but the module itself was eating that up and then disguising it as a 500 like you say. My changes in the commit linked in comment 8 was designed to fix this problem, so somehow it's happening again.

Comment 11

[Pomax]

the problem turned out to be an outdated version of loginapi being the "most recent" on npmjs.org

Updating to 0.1.9 solved this problem.

Comment 12

[Pomax]

http://limitless-everglades-5263.herokuapp.com/ now has the Webmaker SSO added to the publish dialog. It is now time to start filing follow-ups to clean up the source code, as well as the HTML/CSS.

Comment 13

[Pomax]

I'm going to mark this ticket as "initial stand-up done", because it is. There are several follow-through bugs for the tasks we now have before we can consider the goggles integrated:

* https://bugzilla.mozilla.org/show_bug.cgi?id=895600 (may make https://bugzilla.mozilla.org/show_bug.cgi?id=896609 and https://bugzilla.mozilla.org/show_bug.cgi?id=896607 obsolete)
* https://bugzilla.mozilla.org/show_bug.cgi?id=895602
* https://bugzilla.mozilla.org/show_bug.cgi?id=896094