Fwd: [Bug 1103035] Re: Charm needed: Juju GUI

[Gary Poster]

On 01/23/2013 06:26 AM, Nicola 'teknico' Larosa wrote:
> Comments below  derive from discussion by frankban and me.

Thank you for working on this.  Replies below.

> 
>>> Robert Ayres wrote:
>>> I've tested on EC2 and LXC.
>>>
>>> Please see bugs/comments below.
> 
> Gary Poster wrote:
>> My thoughts on these, fwiw.
...
>>> *If you use the 'user', 'password' config options then these can be
>>> obtained simply by accessing the URL - https://xxx/juju- 
>>> ui/assets/config.js .
> 
>> I am inclined to think that this is merely a warning that we add to 
>> those configuration values.  Alternatively, do we have a use case for 
>> this other than improv?  If we don't, maybe we should remove these 
>> options as dangerous and only set the admin/admin authentication with 
>> the "staging" module?
> 
> I like the second option more. The possibility to set supposedly secret
> credentials gives a sense of false security, since those credentials are
> not secret at all.
> 
> If non-improv use cases exist, I would still remove the config options
> and replace them with a skip-auth option, and hardwired credentials like
> "PUBLIC_USERNAME" and "PUBLIC_PASSWORD", to be manually enabled in the
> Juju auth backend, with an explicit warning to the user about the
> consequences. But probably we don't need all this.

OK.  Let me run this by Kapil and see if I can get his blessing on the
simple "staging options automatically sets the admin password" approach,
or another direction.  I'll reply asap--I should see him within the next
two hours.


>>> *I'd mention in the README that you may need to add a https
>>> certificate exception for self-signed certificates for port 8080
>>> ('juju-api-port'). I found I couldn't get the UI to appear unless I
>>> first accessed on port 8080 and accepted the self-signed
>>> certificate.
> 
>> good idea and nice thorough diagnosis
> 
> This should not happen. The charm generates a self-signed certificate,
> then passes it to Juju to be used by the API WebSocket, and finally
> configures it in nginx to be used by the HTTPS connections.

Ah, right, I remember.  So, you approve the cert when you go to the
website, and then it should be fine once it actually starts trying to
connect over the websocket.

Because of the language, I suspect that this is Firefox.  Also, I
noticed that uistage works for me on Firefox (http, not https) so I
wonder if this is what therve also encountered.

> We're trying to reproduce this on different deployment platforms and
> using different browsers. More details from Robert would be useful, I'll
> ask on the bug.

Thank you, I saw this.

I want to file a bug to make our browser support explicit and clear to
people using the charm or even going to uistage. A good start might be
to have the charm's README document our browser support.  The language
should say something like "The Juju GUI supports recent releases of
Chrome and Chromium.  Recent Firefox releases are also supported but
regressions may occur until the completion of upcoming continuous
integration work.  IE 10 will be supported soon."  If you have a
proposal for this language, let me know.  Deryck thought that sounded
fine, FWIW.  (Next steps would be to have the app itself communicate
this information.  I'm not sure how to do that yet.)

Gary