Make the displayed SSH username configurable #12

Merged
mirsal merged 1 commits from mirsal/capsul-flask:ssh-username into master 2021-08-10 09:56:15 +00:00
5 changed files with 8 additions and 5 deletions

View File

@ -58,6 +58,7 @@ app.config.from_mapping(
LOG_LEVEL=os.environ.get("LOG_LEVEL", default="INFO"),
SPOKE_HOST_ID=os.environ.get("SPOKE_HOST_ID", default="baikal"),
SPOKE_HOST_TOKEN=os.environ.get("SPOKE_HOST_TOKEN", default="changeme"),
SSH_USERNAME=os.environ.get("SSH_USERNAME", default="cyberian"),
HUB_TOKEN=os.environ.get("HUB_TOKEN", default="changeme"),
# https://www.postgresql.org/docs/9.1/libpq-ssl.html#LIBPQ-SSL-SSLMODE-STATEMENTS

View File

@ -108,6 +108,8 @@ def detail(id):
if vm is None:
return abort(404, f"{id} doesn't exist.")
vm['ssh_username'] = current_app.config['SSH_USERNAME']
if vm['deleted']:
return render_template("capsul-detail.html", vm=vm, delete=True, deleted=True)

View File

@ -22,7 +22,7 @@ def pricing():
@bp.route("/faq")
def faq():
return render_template("faq.html")
return render_template("faq.html", ssh_username=current_app.config['SSH_USERNAME'])
@bp.route("/about-ssh")
def about_ssh():

View File

@ -97,7 +97,7 @@
</div>
<div class="row justify-start">
<label class="align" for="ssh_username">SSH Username</label>
<span id="ssh_username">cyberian</span>
<span id="ssh_username">{{ vm['ssh_username'] }}</span>
forest marked this conversation as resolved Outdated

I think @forest was saying he preferred that templates not be dependent on the structure of the config, so setting a context variable in the view as here: https://git.autonomic.zone/3wordchant/capsul-flask/src/branch/master/capsulflask/console.py#L429

I think @forest was saying he preferred that templates not be dependent on the structure of the config, so setting a context variable in the view as here: https://git.autonomic.zone/3wordchant/capsul-flask/src/branch/master/capsulflask/console.py#L429

it can be done that way, although there are many calls to render_template() and so adding a context variable to each of them would be error-prone and require many more changes.

@forest would you rather have it passed through the context every time?

it can be done that way, although there are many calls to render_template() and so adding a context variable to each of them would be error-prone and require many more changes. @forest would you rather have it passed through the context every time?

hmm.. I don't think it's any more error prone than putting the config.SSH_USERNAME into the template. I have been hurt by template engines too many times and I tend to try to isolate and validate all inputs into the template before I execute it. In the past, I've encountered template engines that fail silently, or fail with a meaningless error (there is no stack trace inside the template, inside the template no one can hear you scream).

TBH I did not know that it was even possible to reach into a global config object from within the template. In my mental model, the only thing you can access from within the template is exactly what is directly passed to it. Obviously thats not true in flask, but if I could make it true, I would. When dealing with error-prone things that do not always provide good error messages, having a comprehensive inventory of all the moving parts in one place helps a lot.

I think it would help developers debug templates easier if they could simply inspect the data object that gets passed to the template right before it is executed, either through print debugging (logger.debug(object_to_json_string(data_object))) or with a property inspector in a proper debugger.

I guess I believe that its the same error-prone, duplicate code problem either way, but I am strongly biased against template engines and I want to put them all in diapers, even though I don't have enough experience with jinja2 to know for sure if it needs that kind of treatment.

Is this silly? Am I wrong? I don't know. I have been doing it one way and I'm resistant to change 😳

hmm.. I don't think it's any more error prone than putting the ` config.SSH_USERNAME ` into the template. I have been hurt by template engines too many times and I tend to try to isolate and validate all inputs into the template before I execute it. In the past, I've encountered template engines that fail silently, or fail with a meaningless error (there is no stack trace inside the template, inside the template no one can hear you scream). TBH I did not know that it was even possible to reach into a global `config` object from within the template. In my mental model, the only thing you can access from within the template is exactly what is directly passed to it. Obviously thats not true in flask, but if I could make it true, I would. When dealing with error-prone things that do not always provide good error messages, having a comprehensive inventory of all the moving parts in one place helps a lot. I think it would help developers debug templates easier if they could simply inspect the data object that gets passed to the template right before it is executed, either through print debugging (`logger.debug(object_to_json_string(data_object))`) or with a property inspector in a proper debugger. I guess I believe that its the same error-prone, duplicate code problem either way, but I am strongly biased against template engines and I want to put them all in diapers, even though I don't have enough experience with jinja2 to know for sure if it needs that kind of treatment. Is this silly? Am I wrong? I don't know. I have been doing it one way and I'm resistant to change 😳

That's definitely not silly and I do not believe that you are wrong (I think that it is safe in that specific case but it would not be obvious to future contributors)

I'm sending another patch which uses the vm context object instead of adding a new context variable, so we get the best of both worlds ;)

That's definitely not silly and I do not believe that you are wrong (I think that it is safe in that specific case but it would not be obvious to future contributors) I'm sending another patch which uses the `vm` context object instead of adding a new context variable, so we get the best of both worlds ;)
</div>
<div class="row justify-start">
<label class="align" for="ssh_authorized_keys">SSH Authorized Keys</label>

View File

@ -21,13 +21,13 @@
</li>
<li>
How do I log in?
<p>ssh to the ip provided to you using the cyberian user.</p>
<pre class='code'>$ ssh cyberian@1.2.3.4</pre>
<p>ssh to the ip provided to you using the "{{ ssh_username }}" user.</p>
mirsal marked this conversation as resolved Outdated

As above

As above
<pre class='code'>$ ssh {{ ssh_username }}@1.2.3.4</pre>
<p>For more information, see <a href="/about-ssh">Understanding the Secure Shell Protocol (SSH)</a>.</p>
</li>
<li>
How do I change to the root user?
<p>The cyberian user has passwordless sudo access by default. This should work:</p>
<p>The "{{ ssh_username }}" user has passwordless sudo access by default. This should work:</p>
<pre class='code'>
# Linux
$ sudo su -