lp://staging/~frankban/charms/precise/juju-gui/server-auth

Branch merges

Propose for merging

No branches dependent on this one.

Merged into lp://staging/~juju-gui/charms/precise/juju-gui/trunk at revision 79

charmers: Pending requested 2013-07-24

Diff: 1183 lines (+807/-62)

12 files modified

revision (+1/-1)
server/guiserver/apps.py (+9/-3)
server/guiserver/auth.py (+215/-0)
server/guiserver/handlers.py (+18/-4)
server/guiserver/manage.py (+27/-3)
server/guiserver/tests/helpers.py (+78/-0)
server/guiserver/tests/test_auth.py (+231/-0)
server/guiserver/tests/test_handlers.py (+140/-40)
server/guiserver/tests/test_manage.py (+38/-10)
server/guiserver/tests/test_utils.py (+25/-0)
server/guiserver/utils.py (+23/-0)
server/runserver.py (+2/-1)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

87. By Francesco Banconi on 2013-07-25

Changes as per review.

86. By Francesco Banconi on 2013-07-25

Changes as per review.

85. By Francesco Banconi on 2013-07-24

Bumped revision up.

84. By Francesco Banconi on 2013-07-24

Fix typo.

83. By Francesco Banconi on 2013-07-24

Checkpoint.

82. By Francesco Banconi on 2013-07-24

Add auth tests.

81. By Francesco Banconi on 2013-07-24

Add tests for json decode and option validation.

80. By Francesco Banconi on 2013-07-24

Add the auth modules.

79. By Francesco Banconi on 2013-07-24

Implemented the authentication infrastructure.

78. By Francesco Banconi on 2013-07-23

New WebSocket connection implementation.

This branch includes a new WebSocket client
implementation purely based on Tornado.

Dropped the ws4py dependency, previously introduced
as a consequence of the built-in client not
being able to connect to juju-core.

Investigation:
I investigated this problem and found that the
WebSocket server implementation in the standard
go.net library (used by juju-core) requires the
"Origin" header to be sent by the client when the
WebSocket handshake is initiated.
See https://code.google.com/p/go/source/browse/websocket/hybi.go?repo=net#514
lines 514-517.
However, if I read the RFC correctly, this is
not entirely the right behavior: see
http://tools.ietf.org/html/rfc6455#page-18 subsection 8:
"The request MUST include a header field with the name |Origin|
[RFC6454] if the request is coming from a browser client. If
the connection is from a non-browser client, the request MAY
include this header field if the semantics of that client match
the use-case described here for browser clients."
This MP description is going to be long anyway, so please
excuse me if I add some background not really related to
the branch. I was curious about why the Python WebSocket
client library that I traditionally used to live test
the juju-core API changes (python-websocket-client) always
work with the juju-core server. The answer ended up being: if no
origin is provided, that library include as "Origin" in
the request headers the address of the WebSocket server itself
(see https://github.com/liris/websocket-client/blob/master/websocket.py#L441
lines 441-444).
I am not sure this make any sense, but I decided to adopt
this solution as fallback for the client in this branch, i.e.:
if the browser request includes the origin header
(it always should), that header is propagated; otherwise
I send the juju-core API server address.
To be clear, the more I think about it, the more I am
convinced that this is NOT a bug in the Tornado client
(which, anyway, allows for adding arbitrary headers almost
easily, as shown in the code).
That's it: I am really interested in your opinion.

Other changes:
Improved logging.
Moved the message queue from the client to the server.
Improved the way disconnections are handled (both browser
and Juju API disconnections).
Improved the way possible API connection problems are handled.

Tests:
Run `make unittest` from the branch root.

QA:
It's not required and, at this time, not easy to set up.
Do it only if you are particularly interested/curious.
Instructions follow.

- Bootstrap juju-core, deploy and expose the juju-gui charm:

    juju bootstrap -e go --upload-tools
    juju deploy -e go cs:precise/juju-gui
    juju expose -e go juju-gui

- Run `juju status -e go` and retrieve the bootstrap
  node and the juju-gui addresses. From now on, I will
  call the former JUJU-BOOTSTRAP-ADDRESS and the latter
  JUJU-GUI-ADDRESS.

- Wait until the juju-gui service is started.

- Get a copy of this branch:

    bzr branch lp:~frankban/charms/precise/juju-gui/new-ws-client/

- Copy the gui-server files in the juju-gui node by
  running the following command from the branch root:

    rsync -av server/ ubuntu@JUJU-GUI-ADDRESS:/home/ubuntu/server

- Ssh into the juju-gui machine:

    juju ssh -e go 1

- In the juju-gui node, all the commands must be run as root:

    sudo -i

- Stop apache and haproxy:

    service apache2 stop
    service haproxy stop

- Set up the gui-server dependencies:

    apt-get install python-pip
    pip install tornado

- Start the gui-server:

    cd /home/ubuntu/server/
    python runserver.py \
    --guiroot="/var/lib/juju/agents/unit-juju-gui-0/charm/juju-gui/build-prod" \
    --jujuapi="wss://JUJU-BOOTSTRAP-ADDRESS:17070"

- Navigate to JUJU-GUI-ADDRESS with your browser. You should be
  redirected to https://JUJU-GUI-ADDRESS. Accept the untrusted
  certificate and start playing with the GUI.

- See the terminal for gui-server access logs. To enable debug
  logging, quit the server (CTRL-c) and restart it adding `--logging=debug`
  to the list of the options above. At this point the output should
  include the contents of the received WebSocket messages.

- Done, thank you!

R=teknico, gary.poster
CC=
https://codereview.appspot.com/11675043