Make the displayed SSH username configurable #12
@ -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
|
||||
|
||||
@ -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)
|
||||
|
||||
|
||||
@ -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():
|
||||
|
||||
@ -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 пометить этот разговор как разрешённый
Устаревшее
|
||||
</div>
|
||||
<div class="row justify-start">
|
||||
<label class="align" for="ssh_authorized_keys">SSH Authorized Keys</label>
|
||||
|
||||
@ -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 пометить этот разговор как разрешённый
Устаревшее
3wordchant
прокомментировал(а)
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 -
|
||||
|
||||
Ссылка в новой задаче
Block a user
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?
hmm.. I don't think it's any more error prone than putting the
config.SSH_USERNAMEinto 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
configobject 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
vmcontext object instead of adding a new context variable, so we get the best of both worlds ;)