Two issues are fixed:
- Initial `docker build` instructions fail because the Dockerfile path
is wrong (elixir/Dockerfile versus elixir/docker/Dockerfile).
- Indexing instructions are wrong because they do not use the
virtualenv Python. It contains the installed packages, which we need
for indexing. Issue appears as:
ModuleNotFoundError: No module named 'bsddb3' (edited)
We also remove some common Docker knowledge (why we might want the
database to be coming from a mounted volume, rather than stored inside
the container).
Finally, we fix line widths but splitting commands into multiple lines.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
We reword the TODO message. We put two newlines before and after the
triple dashes to avoid Markdown title formatting.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Now making a GET to /project/version/ident will redirect to
/project/version/source.
Refreshing a page after making a request for an empty identifier won't
show 405 Method Not Allowed anymore.
This is NOT being served by Elixir backend. The HTTP server in front
must serve it. Commit robots.txt to store the file somewhere.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
For some reason, browsers do not automatically pick up the hosted
favicon.ico available on staging server. Add an explicit line to
describe the availability of /favicon.ico.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
favicon.ico being served is not dependent on Elixir's configuration, but
on the front-facing server. Its config must be updated to serve the
favicon; this is why favicon.ico used to not be commited into the
repo.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Mark the searchbar as a required input. This avoids <Enter> on an empty
searchbar to send a "POST /$PROJECT/$VERSION/ident" with empty value,
which triggers an error.
This is made more frequent by the fact that the searchbar is
automatically focused. It also avoids implementing logic on the backend
to redirect to the previous page if an empty search was submitted.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Fixes the following bug:
1. Make sure show-menu == true
2. Open page in mobile mode
3. Reisze to widescreen
Sidebar will be hidden until page is reloaded.
As usual, we must increment those version numbers when changes are made
to style.css and/or script.js. That purges the production cache.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
As usual, we must increment those version numbers when changes are made
to style.css and/or script.js. That purges the production cache.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
As usual, we must increment those version numbers when changes are made
to style.css and/or script.js. That purges the production cache.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
As usual, we must increment those version numbers when changes are made
to style.css and/or script.js. That purges the production cache.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
The local storage API returns strings and has no way to set a default
value in case no value exists. We must therefore check for the "true"
string or the null value.
Let's extract it from the if boolean expression. We go from:
if (isWidescreen && (showSidebar === "true" || showSidebar === null))
To:
if (isWidescreen && showSidebar)
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Backwards compatibility for browsers without svg support (in this
version) causes the logo to unnecessarily flicker on navigation.
According to caniuse.com SVG in img elements is supported in browsers
used by 97.85% of users. https://caniuse.com/svg-img
Firefox introduced support in 2011, Chrome in 2013, Safari in 2015.
This parameter makes the server return a response with raw file
contents and headers that cause the browser to show a 'save as' dialog.
Regarding Content-Security-Policy:
https://www.w3.org/TR/CSP2/#sandbox-usage
> For example, a message board or email system might provide downloads of
> arbitrary attachments provided by other users. Attacks that rely on tricking
> a client into rendering one of these attachments could be mitigated by
> requesting that resources only be rendered in a very restrictive sandbox.
> Sending the sandbox directive with an empty value establishes such an
> environment:
>
> Content-Security-Policy: sandbox
https://www.w3.org/TR/CSP2/#directive-default-src
> Given this behavior, one good way of building a policy for a site would be to
> begin with a default-src of 'none', and to build up a policy from there that
> contains only those resource types which are actually in use for the page
> you’d like to protect. If you don’t use webfonts, for instance, there’s no
> reason to specify a source list for font-src; specifying only those resource
> types a page uses ensures that the possible attack surface for that page
> remains as small as possible.
https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html#defense-in-depth
> A strong CSP provides an effective second layer of protection against various
> types of vulnerabilities, especially XSS. Although CSP doesn't prevent web
> applications from containing vulnerabilities, it can make those
> vulnerabilities significantly more difficult for an attacker to exploit.
The idea is to prevent the browser from loading any external resources, if it
turned out it's possible to trick it into interpreting a file as HTML.
