Authentication, "authenticated", and "anon"

#1

I’m using the parameter described at:

WebServer Authorization

…and I have a coupe of issues.

I’d like to have a wiki which is world-readable, and writable by authenticated users. My guess, under the shell script:

#!/bin/sh
tiddywiki whatever --listen \
        [...irrelevant stuff...] \
        credentials=creds.csv \
        "readers=(anon)" \
        writers=michael

The behavior of my wiki has been unpredictable.

Currently, I’m getting a wiki which is world-readable only. The “writers” part doesn’t seem to be in effect.

A hitch: it’s hard to be sure that my setup is currently in effect, and, which such setup applies on the browser end.

I’ve tried varying sequences of:

  • changes within the “creds.csv” file;
  • restart the web server (nginx);
  • restart the shell script where tiddlywiki is running;
  • stop the shell script; reload at the browser (to force “file not found”); restart the script and restart the browser side;
  • switch around between “readers=(anon)”, “readers=(authenticated)”, and (varying entries under) the “writers=” entry;
  • force restart of my browser (shift-reload as opposed to just a reload of the page)

Whatever I’ve done on the server side, it’s rare that my page is fully reloaded at the browser. Sometimes I do get the user/password prompt, but not very often, and I don’t see any way to force a complete reload. Specifically, once I have a session with “writers=” enabled, changes on that entry at the script end don’t seem to matter from the browser right away.

As I write this, my current user session is the “anon” kind – the page reloads with no errors, but no “write” options appear (create a tiddler, synchronization). Earlier, the full writable status was appearing, but I haven’t been able to narrow down how to force a switch among the various settings.

It’d be handy to have more than one entry under the “credentials=” file, then, as a user, restart a session between those user states. Or, short of that, to reload different versions of that .csv file; either way though, what I find is that it seems my browser keeps some set of data that it reloaded in some past session. That makes it difficult to verify that the current status of the shell script is up to date.

One thought I had: taking out the “user-browser-cache=” setting, maybe that would stop the pattern of having the browser send whatever it might have cached. It didn’t make any difference other than (as expected) slower reloads of a page.

Hints? Thanks.

1 Like
#2

Maybe try the less secure method of putting the password in the commands to see if that works as well as shown in WebServer. It could be a permissions issue with your credentials file if the latter works or the location of the credentials file relative to the tiddlywiki.info file.

#3

also, just to be clear - you are going to yourwebsite.com/login-basic to login?

#4

Out of order here; first:

also, just to be clear - you are going to yourwebsite.com/login-basic to login?

No; in this instance, I have:

website.com/thing/
website.com/other-thing/

…where each “thing” has its own TW housed within it. If I tack anything onto the end of a URL, like:

https://website.com/thing/login-basic

…that isn’t handled; the server bounces us back to the base of the site:

https://whatever.com/

…where we get the server’s default link to a flat “oops” page. My guess is, this could be handled if I knew what to fill in somewhere.

In case this is relevant, it’s my latest from a process I/we have been describing, at Multiple instances, each under HTTPS

Backing up:

Maybe try the less secure method of putting the password in the commands to see if that works as well as shown in WebServer.

Thanks for that, I’d forgotten about it.

I am currently hitting a snag though, one of the issues I described. I set up the relevant shell script, with username/password in the shell command; then, for my first test, at the triggered login window, I cancelled the login session popup. That has my session going in a public status – which is fine – but since I don’t find a way to re-trigger the login window, I don’t know yet what will happen when I do log in successfully.

1 Like
#5

…which, I guess, is just a repeat of what I tried to describe in the first place.

So, I’m thinking that I need to solve what I just described, the auto-bump back to the root of the service. Is there something to put on some “$__(something)” file, that will handle rewriting “/site/” to something other than “/”?

For example, at that current HowTo we have:

$__config_tiddlyweb_host.tid

…and related bits, which is what handles starting a session on the extended root name. Is there something that would do the same thing, on outward-bound connections? Forgive my inaccurate terminology here.

I don’t know how much that pertains to the issue I’m trying to resolve, but, one piece at a time.

#6

More on this: after (I’m assuming) a timeout which triggered a login, I was able to try a successful user/password, but it’s worse with the “less secure” setup. When I try to log in with a correct password, that fails, and the user is popped to that default system root page.

#7

Looking at your setup where you are using nginx to, I assume, proxy-pass to the nodejs server : I have never had any success proxying to a directory domain like that. I always just use subdomains for proxied servers : thing.website.com, etc. That could honestly be the core issue seeing how trying to go to /login-basic bounces you back. It could be that you need a redirect to /login-basic in your nginx config file but it’s just never been worth the time to troubleshoot.

I assume you are probably using lets-encrypt for your certificates. I have my domains through google but I route through cloudflare for free and they allow the use of wildcard certs with lets-encrypt. I’ll dig up some sources if that is an issue and you want to go that route.

So my guess is it’s an issue with nginx and how it is proxying. Your error/access logs may help.

1 Like
#8

If I understand you correctly I find that using ‘incognito’ or ‘private’ browsing is great for troubleshooting these problems.

1 Like
#9

Incognito (etc.) is one of those “never would have thought of it, obvious in hindsight” things. So sincerely, thank you for improving my brain.

1 Like
#10

A confession: I was unaware of Let’s Encrypt until about two days after I started all this. So, of course, my keys are not as good as they would have been. (And I was wishing for this service with a “what, why not?” decades ago. So it goes.) Oops.

Now I wonder if that HowTo I helped write should be replaced with something more like, “don’t do it that way, do it this way.”

1 Like
#11

as rewarding as self-learning can be, it is a tortuous journey of trial and error that is for sure. Especially with networking I have spent countless hours on the most mundane problems that I was making so much more complicated than it had to be.

this blog entry has helped me a lot. Even if you don’t purchase your domain from cloudflare you can still use them to route your domains.

good luck and as a fellow hobbyist I’ll help any way I can. Putting TW online like this adds a whole layer of complexity but it also makes it infinitely more useful for me.

I am moving stuff around right now to make use of oracles free cloud tiers but for now my setup is using docker containers on a vps - one for nginx and one for tw nodejs servers.

Also check out the tw reciever plugin that uses php to serve and save singfile tiddlywikis. That link is my fork. The original is here.

Happy hacking!!

1 Like
#12

If you are setting the $:/config/tiddlyweb/host tiddler correctly, then the issue is with basic authentication credentials. The first time a server gives a valid response, the browser saves the passed credentials from that request FOR THE SESSION. There is no way to re-validate until the browser is restarted (or incognito mode is closed and restarted). Anon mode complicates this further by authenticating requests before credentials are entered.

See: [BUG] Basic auth fails when (anon) is used in the principles and previously cached credentials sent · Issue #5802 · Jermolene/TiddlyWiki5 · GitHub

Remove Anon Mode, and setup the TW Server to render out another wiki as the anon-readable version.

1 Like
#13

Thanks for this.

Forgive my vacant brain, but as I read this and the bug you posted, I’m guessing that the best way to proceed is the one I already have in mind, switch from:

https://website.here/foo/

…to…

https://foo.website.here/

…and handle deployment of new sessions via DNS, not path names?

#14

This is what has worked for me in the past. Trying to get nginx to proxypass pathnames has always led to headaches.

1 Like