Basic Auth + SSL seems just fine to me. Without a lot of thought, my immediate concern would be that the credentials have to be used on every request and will be cached temporarily by the browser being used. But, that doesn’t seem to be a concern for where this tool would be used (by one person, from one machine, probably).
I see a lot of basic auth + ssl used in things like Sentry which are much less likely to have a “session,” but do seem to operate in practice quite securely.
The abuse scenario for this is CSRF, where an already authenticated user visits another malicious website, and that malicious website creates requests for Minisleeps. They get through because the user is already authenticated.
my immediate concern would be that the credentials have to be used on every request and will be cached temporarily by the browser being used.
Yes, unfortunately this method doesn’t provide a “log out” button. It’s browser implementation dependent how these credentials are dropped, in FF’s case it’s when you close the browser.
There is (as far as I can tell) no workaround. It’s a limitation of the browsers themselves + perhaps the HTTP standards. Ever since online culture went to custom login forms & cookies I suspect that interest in developing HTTP auth waned.
I like it! If someone created a static executable with a HTTP Server + Minisleep embedded into it, would that be interesting? This should be straightforward to do with Go. It would make the deployment even easier.
You can probable get a static HTTP server and a static shell interpreter already off the shelf. I’m not sure why you would specifly want to add Go to the mix however, unless you’re planning on rewriting the main script in it?
If you are going to copy in bash files, why not copy in a single statically compiled executable instead? Go just makes this convenient, since there’s a good HTTP server in the standard library, statically compiled executables are the default and several platforms are supported.
To customise page layout & links or change the markup engines you need to be able to edit one of the provided scripts. Providing a pre-compiled version of the project would be useless for most people, unless they’re happy for the site to look stock (complete with a header link to the docs & my website).
I’ve also found that pre-compiled bins are harder to get working on some shared hosts than shell scripts. Some hosts run really old or obscure versions of libs or kernel setups; one host wouldn’t accept things I compiled in any way (even my static attempts) on Debian stable for instance. These hosts tend to require you to jump through extra hoops to get (temporary) access to their buildchain. They prefer customers with php, js-ey or perl sites. I think they do this intentionally to try and avoid compiled/obscured malware, but I’m not sure.
IMHO self-contained shell scripts already provide the ‘runnable anywhere without fetching anything’ goal of static executables. I’m not sure what comparative benefits static executables would actually provide here.
This seems a bit exaggerated, TBH. If Pandoc doesn’t cut it, you can always scrape the HTML and use XSLT to produce the target markup. It’s a weekend of work for a CS grad. But it’s a good reminder that any application should have a “data liberation” feature.
I find some irony in “Shell scripts are one of the lowest common denominators across all webhosts.” and then “You’re almost guaranteed to have bash already”.
I think shell is a great language for simple tools, but IMO if plain sh isn’t enough - it’s a sign you should probably use a more featured language anyway.
But as you say - you were scratching your own itch, so congrats on releasing, brother (sister?).
Minisleep was derived from a project that regularly used bash features (such as shopt -s nullglob). There are ways around needing this, but they require more complicated code, something I want to avoid in a language already renowned for weird complexities.
I don’t think Minisleep actually uses/requires any Bash-only features. I develop using bash because of debugging conveniences such as ‘set -o pipefail’. Perhaps this is a bit similar to the ‘arm on servers doesn’t succeed because developers use x86 desktop/laptops’ argument.
(I’m the author of Minisleep)
I’m particularly interested on people’s views of the security model.
Otherwise: all feedback welcome.
Basic Auth + SSL seems just fine to me. Without a lot of thought, my immediate concern would be that the credentials have to be used on every request and will be cached temporarily by the browser being used. But, that doesn’t seem to be a concern for where this tool would be used (by one person, from one machine, probably).
I see a lot of basic auth + ssl used in things like Sentry which are much less likely to have a “session,” but do seem to operate in practice quite securely.
The abuse scenario for this is CSRF, where an already authenticated user visits another malicious website, and that malicious website creates requests for Minisleeps. They get through because the user is already authenticated.
Thanks Joel.
Yes, unfortunately this method doesn’t provide a “log out” button. It’s browser implementation dependent how these credentials are dropped, in FF’s case it’s when you close the browser.
There is (as far as I can tell) no workaround. It’s a limitation of the browsers themselves + perhaps the HTTP standards. Ever since online culture went to custom login forms & cookies I suspect that interest in developing HTTP auth waned.
On Apache at least, you could use mod_auth_form - it’s a ‘regular’ form + cookie session model, but its driven by apache itself not php/ruby/etc app. https://httpd.apache.org/docs/2.4/mod/mod_auth_form.html
I like it! If someone created a static executable with a HTTP Server + Minisleep embedded into it, would that be interesting? This should be straightforward to do with Go. It would make the deployment even easier.
You can probable get a static HTTP server and a static shell interpreter already off the shelf. I’m not sure why you would specifly want to add Go to the mix however, unless you’re planning on rewriting the main script in it?
If you are going to copy in bash files, why not copy in a single statically compiled executable instead? Go just makes this convenient, since there’s a good HTTP server in the standard library, statically compiled executables are the default and several platforms are supported.
To customise page layout & links or change the markup engines you need to be able to edit one of the provided scripts. Providing a pre-compiled version of the project would be useless for most people, unless they’re happy for the site to look stock (complete with a header link to the docs & my website).
I’ve also found that pre-compiled bins are harder to get working on some shared hosts than shell scripts. Some hosts run really old or obscure versions of libs or kernel setups; one host wouldn’t accept things I compiled in any way (even my static attempts) on Debian stable for instance. These hosts tend to require you to jump through extra hoops to get (temporary) access to their buildchain. They prefer customers with php, js-ey or perl sites. I think they do this intentionally to try and avoid compiled/obscured malware, but I’m not sure.
IMHO self-contained shell scripts already provide the ‘runnable anywhere without fetching anything’ goal of static executables. I’m not sure what comparative benefits static executables would actually provide here.
Some extra reading: “The wiki trap” https://utcc.utoronto.ca/~cks/space/blog/web/WikiTrap
This seems a bit exaggerated, TBH. If Pandoc doesn’t cut it, you can always scrape the HTML and use XSLT to produce the target markup. It’s a weekend of work for a CS grad. But it’s a good reminder that any application should have a “data liberation” feature.
I find some irony in “Shell scripts are one of the lowest common denominators across all webhosts.” and then “You’re almost guaranteed to have bash already”.
I think shell is a great language for simple tools, but IMO if plain
shisn’t enough - it’s a sign you should probably use a more featured language anyway.But as you say - you were scratching your own itch, so congrats on releasing, brother (sister?).
Most people don’t stop and think about if they actually need bash features. To them, shell and bash are synonymous.
Yup, very much so.
Thanks stephenr.
Minisleep was derived from a project that regularly used bash features (such as shopt -s nullglob). There are ways around needing this, but they require more complicated code, something I want to avoid in a language already renowned for weird complexities.
I don’t think Minisleep actually uses/requires any Bash-only features. I develop using bash because of debugging conveniences such as ‘set -o pipefail’. Perhaps this is a bit similar to the ‘arm on servers doesn’t succeed because developers use x86 desktop/laptops’ argument.