aboutsummaryrefslogtreecommitdiff
path: root/web
AgeCommit message (Collapse)AuthorFilesLines
2025-04-01various: fix minor typos (#187)Patrick Linnane1-1/+1
Signed-off-by: Patrick Linnane <patrick@linnane.io>
2025-03-31web/js: Added a wait with button continue + 30 second auto continue after ↵Cyra Westmere2-29/+113
30s if you click "Why am I seeing this? (#166) * web/js: update page to allow users to read the "Why am I seeing this?", complete with a button to send them through after challenge completed, and a 30s timeout that does the same. * .gitignore: added .DS_store. * docs/docs/CHANGELOG: added to the Unreleased section as requested in code quality guidelines * web: pushing index_templ.go alongside this update. * package.json: added postcss to dependencies list. * package-lock: added postcss to dependencies * Revert "package-lock: added postcss to dependencies" This reverts commit bf02e7ba56e8bf8705821d4f4864c66b1ef614bf. * Revert "package.json: added postcss to dependencies list." This reverts commit 1a38c63049dc75099dc652ed725c7862eef4b3e4. * web/js: OG comments are important --------- Signed-off-by: Xe Iaso <me@xeiaso.net> Co-authored-by: Xe Iaso <me@xeiaso.net>
2025-03-29web/js: Add LibreJS banner to Anubis JavaScript to allow LibreJS users to ↵Fijxu1-1/+29
run the challenge (#161) * web/js: add project license in the JavaScript used by Anubis This will allow LibreJS users to pass the captcha without problems without having to whitelist anubis manually. * Update docs/docs/CHANGELOG.md Co-authored-by: Xe Iaso <me@xeiaso.net> Signed-off-by: Fijxu <fijxu@nadeko.net> --------- Signed-off-by: Fijxu <fijxu@nadeko.net> Co-authored-by: Xe Iaso <me@xeiaso.net>
2025-03-29Debug tool for benchmarking proof-of-work algorithms (#155)jae beller8-7/+303
* cmd/anubis: add a debug option for benchmarking hashrate Having the ability to benchmark different proof-of-work implementations is useful for extending Anubis. This adds a flag `--debug-benchmark-js` (and its associated environment variable `DEBUG_BENCHMARK_JS`) for serving a tool to do so. Internally, a there is a new policy action, "DEBUG_BENCHMARK", which serves the benchmarking tool instead of a challenge. The flag then replaces all bot rules with a special rule matching every request to that action. The benchmark page makes heavy use of inline styles, because currently all global styles are shared across all pages. This could be fixed, but I wanted to avoid major changes to the templates. * web/js: add signal for aborting an active proof-of-work algorithm Both proof-of-work algorithms now take an optional `AbortSignal`, which immediately terminates all workers and returns `false` if aborted before the challenge is complete. * web/js: add algorithm comparison to the benchmark page "Compare:" is added to the benchmark page for testing the relative performance between two algorithms. Since benchmark runs generally have high variance, it may take a while for the averages to converge on a stable difference. --------- Signed-off-by: Xe Iaso <me@xeiaso.net> Co-authored-by: Xe Iaso <me@xeiaso.net>
2025-03-29Show a progress bar for the probability of completing the proof of work ↵jae beller5-144/+118
challenge (#87) Since the challenge is done off of the main thread, there is no simple way to report the progress done towards completing it. This change adds a callback parameter, `progressCallback`, which is called with the most recently attempted nonce every ~1024 iterations (should this be configurable?). For the single-threaded "slow" algorithm, this is exactly every 1024 iterations. For the multi-threaded "fast" algorithm, threads take turns reporting in a round-robin as then notice they have passed a multiple of 1024. This complexity is to avoid individual threads falling behind their siblings due to the overhead of messaging the main thread. To minimize this overhead as much as possible, a regular number is sent instead of an object. With the new information provided by the callback, a hash rate display is added to the challenge page. This display is updated at most once per second and set with tabular numbers to avoid the constantly changing value being too visually distracting. * web: show a progress bar based on completion probability To provide more feedback to the user, the spinner is replaced with a progress bar of the probability the challenge is complete. Since it looks a little weird that a progress bar would fill up a quarter of the way and then jump to the end (even though the probability would make that happen 1 in 4 times), the bar is mapped with a quadratic easing function to move faster at the beginning and then slow down as the probability of redirection increases. If the probability exceeds 90%, a message appears letting the user know things are taking longer than expected and to continue being patient. Signed-off-by: Xe Iaso <me@xeiaso.net>
2025-03-28web/js: show more errors when some probable error cases happen (#151)Xe Iaso3-35/+100
Closes #150 This should hopefully make Anubis more self-describing when errors do happen so users can self-service.
2025-03-28all: do not commit generated JS/CSS to source control (#148)Xe Iaso8-13/+12
Closes #125 Closes #40 Among other things, this moves all of the asset generation to run within the context of an npm script. Developer documentation stubs have been added so that people can get started more easily. The top-level Dockerfile (which is no longer used in production) has been removed as its presence has been causing confusion. This changeset will break it anyways. These changes will make for less "repo churn" as the static assets are built and rebuilt, at the cost of making the build step more complicated for downstream packagers. If this becomes a burden, we can explore making a "release tarball" that contains pre-massaged outputs.
2025-03-22Refactor and split out things into cmd and lib (#77)Yulian Kuncheff18-0/+788
* Refactor anubis to split business logic into a lib, and cmd to just be direct usage. * Post-rebase fixes. * Update changelog, remove unnecessary one. * lib: refactor this This is mostly based on my personal preferences for how Go code should be laid out. I'm not sold on the package name "lib" (I'd call it anubis but that would stutter), but people are probably gonna import it as libanubis so it's likely fine. Packages have been "flattened" to centralize implementation with area of concern. This goes against the Java-esque style that many people like, but I think this helps make things simple. Most notably: the dnsbl client (which is a hack) is an internal package until it's made more generic. Then it can be made external. I also fixed the logic such that `go generate` works and rebased on main. * internal/test: run tests iff npx exists and DONT_USE_NETWORK is not set Signed-off-by: Xe Iaso <me@xeiaso.net> * internal/test: install deps Signed-off-by: Xe Iaso <me@xeiaso.net> * .github/workflows: verbose go tests? Signed-off-by: Xe Iaso <me@xeiaso.net> * internal/test: sleep 2 Signed-off-by: Xe Iaso <me@xeiaso.net> * internal/test: nix this test so CI works Signed-off-by: Xe Iaso <me@xeiaso.net> * internal/test: warmup per browser? Signed-off-by: Xe Iaso <me@xeiaso.net> * internal/test: disable for now :( Signed-off-by: Xe Iaso <me@xeiaso.net> * lib/anubis: do not apply bot rules if address check fails Closes #83 --------- Signed-off-by: Xe Iaso <me@xeiaso.net> Co-authored-by: Xe Iaso <me@xeiaso.net>