webring_bounce's Introduction

webring_bounce

This WSGI app provides bounce URLs to HTML-driven webrings.

Bounce URLs

Random site: /random?ring=...&from=...
Next site: /next?ring=...&from=...
Previous site: /prev?ring=...&from=...

Define webrings directly in HTML

See the bounce URLs? The ring argument should be a URL to a webpage. The app will scan that webpage for <a> elements with their rel attribute set to "webring-member". Example:

<p>Welcome to my Grand Canyon webring!!! The members of this ring are:</p>
<ul>
    <li><a rel="webring-member" href="https://example.org/">Best picture spots in the Grand Canyon</a></li>
    <li><a rel="webring-member" href="https://example.net/">History: The Grand Canyon</a></li>
</ul>

Additionally, a second argument from should contain the member site you're originating from, i.e. the user's current location. With both arguments, ring and from, the app can now shuttle the user to the correct next website.

And that's how it works.

Running for local development

Invoking webring_bounce.py will start Python's built-in WSGI server.

$ export WEBRING_WHITELIST="https://chillycider.github.io/webring/"
$ export CACHE_SPEC=sqlite://webring_cache.db
$ export HOST=127.0.0.1
$ export PORT=3000
$ python3 webring_bounce.py
webring_bounce v0.1
===================
Listening on 127.0.0.1 port 3000.

*  Note: You are using the built-in Python WSGI server. If this service
*  is intended to be accessible from the public Internet, then please
*  use a more secure server such as gunicorn (Green Unicorn).

Deploying for real

Here's a workable example for gunicorn.

$ gunicorn -k gevent -b 0.0.0.0:3000 -w 3 \
      -e WEBRING_WHITELIST="https://chillycider.github.io/webring/" \
      -e CACHE_SPEC=sqlite:///tmp/webring_cache.db \
      webring_bounce:app

Frequently Asked Questions

Why do webrings have to be whitelisted?

It's a security measure to stop bots from flooding the SQLite cache with URLs. It's also a first line of defense against abuse such as that described in issues #1 and #3.

Consider also that a strict whitelist makes it tough for instances to get too widely used, discouraging a single point of failure.

Why does this app even exist?

To increase the capabilities of HTML-only websites such as those hosted on Neocities.

License

Contributing

This project is open to new ideas and pull requests. Also, if you find a bug, feel free to tell us on the issue tracker.

If you want to submit a PR, I require that you include this disclaimer with your PR:

I dedicate any and all copyright interest in this software to the public domain. I make this dedication for the benefit of the public at large and to the detriment of my heirs and successors. I intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this software under copyright law.

Attaching that to your PR will keep the project unquestionably in the public domain.

webring_bounce's People

Contributors

Watchers

webring_bounce's Issues

Add testing

This may require refactoring into testable functions.

If an ETag matches, then we should mark the cache entry as up-to-date (as if the entry was completely fresh)

Do something to prevent endless redirects

If a webring has our bounce URLs as one of its members, it's possible to send the user on an endless series of redirects.

I don't see a satisfactory way to fix this. Right now, we can only hope that whitelisted webrings are trustworthy enough not to do this.

There's no cap on the number of HTTP fetches being run at a time

We need a way to coordinate between gunicorn/uWSGI/etc. workers to make sure only 1 fetch operation is ever being performed at a time.

Maybe we can leverage our SQLite cache?

Otherwise, we might have to resort to an external solution. (I'd prefer not to do this, because I like how this repo is a self-contained and complete WSGI app)

Use cached data if an timeout occurs while fetching the ring page

Right now, we just error out if the ring fetch request times out.

Instead, it would be cool if our cached data would be used in those cases. If no cached data is present, then we should fall back onto the current behavior.