Don't add username and password in deployed HTML

[mgeisler]

For ease of testing, zpm deploy inserts the Swift username and password into the generated index.html file. This is so that the JS code we run can authenticate before executing the job.

We need to figure out a better way of handling this.

[larsbutler]

I have a couple of ideas about this. Have a look at https://github.com/zerovm/zwift-ui/blob/master/js/Swift.js. You can grab various bits of information from global vars. Have a look at window.SwiftV1 in a console. Probably we can extract just about everything we need (except for maybe the password).

[mgeisler]

When you zpm deploy, the UI template files (such as index.html.tmpl) are run through Jinja2. When rendering the template, an auth_opts JSON string is available which has the authentication information used by zpm deploy. If you add --no-ui-auth, then this string is empty, otherwise it contains the credentials zpm deploy is about to use when deploying.

We don't use the Swift.js file from the file manager. If you load the web UI we auto-generate after logging into to ZeroCloud, then you need no further authentication — the cookies set when you login to ZeroCloud are reused for the Swift operations. If you're not logged into ZeroCloud, then you'll need to supply credentials some other way.

That way is currently by hard-coding them. An alternative would be to render a HTML form where the user can supply the username and password. When we have the credentials, the rest is already handled: the tiny client in zerocloud.js knows how to authenticate with them.

[larsbutler]

Hard-coding is not ideal. If someone makes their index.html publicly readable, anyone can see their complete credentials in plain text!

Is there no way we can get what we need from cookies or session information?

[pkit]

@mgeisler so, we probably can just disable all the auth in html/js
If the user is using zerocloud with correct auth it will work as usual, and if they want to use some other sort of auth - it's their problem. We cannot support all auth types, at least not keystone. :)

[mgeisler]

@larsbutler

Is there no way we can get what we need from cookies or session information?

We can and we do exactly that. You need to use zpm --no-ui-auth and then you'll get a index.html without any hard-coded credentials.

[mgeisler]

@pkit We support v1 and v2 auth. I originally tested this on my devstack installation where the JS would auth with keystone first. Now I've mostly tested it with Zebra (i.e., without any JS authentication).

[pkit]

@mgeisler Dunno, v1 and v2 are keystone terms. In Swift terms there is no such thing, and authorization strings can be different even in various v1 (keystone vs. tempauth, as an example).
So, leaking sensitive info by adhering to some strange auth types doesn't sit well with me

[larsbutler]

@mgeisler

We can and we do exactly that. You need to use zpm --no-ui-auth and then you'll get a index.html without any hard-coded credentials.

It omits the username/password, yes, but I don't think that completely solves the problem. If I want to then run my app from the index.html, where does it get my credentials?

Now that I'm really looking at (I don't use the UI often), if I try to run even a simple "hello world" zapp (like in the Zebra tutorial) from the web UI, I get errors like this in my console:

Uncaught TypeError: Cannot read property 'replace' of undefined zerocloud.js:168

This happens with --no-ui-auth and without it. Looks like a separate issue, and I think I know the cause. I'll submit a fix.

[larsbutler]

Okay, so it does work without the credentials rendered to the index.html. The question is, how? I don't understand what's going on there.

[pkit]

He-he, it's simple: cookies. Cookies are sent along with your request, no matter what you request.
Cookies are parsed by liteauth and placed as headers on top of the request, voilà, you've got authorized.

[larsbutler]

How can I see what those cookies look like? I'm looking in my console (Chrome) and I see Resources -> Cookies. I can also see document.cookie, but there's nothing interesting in either of these. O.o Where should I look?

[larsbutler]

Ah, wait. There's the authtoken in session. I guess that's it.

[pkit]

Yep, that's it.
You cannot get it from javascript, for security reasons. :)

[larsbutler]

Okay, so in that case, I think we should remove the --no-ui-auth option and just make that the default.

[pkit]

It would be hard to test without devstack-ing liteauth into equation, but it could be a great thing. :)

[mgeisler]

Lars Butler [email protected] writes:

Okay, so in that case, I think we should remove the --no-ui-auth
option and just make that the default.

I think making it the default would be a good idea.