Fossil Forum
Post: How can one prevent the anti-robot defense from applying to the repolist?
Hi,
I download the repolist page from a script to easily clone and sync all my repositories from unprivileged places. Can the robot defense be disabled? I see robot-exception and robot-restrict settings, but the repolist page is at the root of the URL, outside of a specific repository, thus I don't see how I can use them to solve this issue.
Thanks.
I recently had this same problem. It turns out that if you use a repolist-skin (as described in the repolist section here), then that repolist skin repository acts as a kind of repository db for the repolist page.
For my setup, i hardcoded the skin path so i could have a working copy, ie. in my fossil cgi script i have:
#!/usr/local/bin/fossil
directory: /path/to/my/fossils
repolist
skin: /path/to/a/checkout/of/my/skin
And in the working dir (checkout) of my skin, there's:
$ cd /path/to/a/checkout/of/my/skin
$ fossil settings robot-restrict --value
off
Doing it this way means that my repolist is restricted to a single skin, which is what i want.
However, if setting skins is not for you, then i think (and this is untested by me) that creating a .fossil config file in the home directory of whatever user you use to run your web fossil could also hold the db settings. Provided that web account has a home directory that exists...
I recently had this same problem. It turns out that if you use a repolist-skin (as described in the repolist section here), then that repolist skin repository acts as a kind of repository db for the repolist page.
eg, put the appropriate skin repository file somewhere within your public fossils directory and set:
$ fossil setting repolist-skin 2 -R /srv/fossils/skin.fossil
$ fossil setting robot-restrict off -R /srv/fossils/skin.fossil
However, if setting skins is not for you, then i think (and this is untested by me) that creating a .fossil config file in the home directory of whatever user you use to run your web fossil could also hold the db settings. Provided that web account has a home directory that exists...
@imagic, i've corrected my earlier reply, so i'm letting you know now just in case you're only following via email as edits to posts don't get an email notification.
The original bit i'd written about setting "skin: ..." in my cgi was so that repositories opened via repolist used that skin, and not relevant to your query.
I already use a repolist skin, I should have tried that. The repository I use for the skin is just a normal repository, but creating a specific one is a simple workaround if I want to preserve the anti-robot defenses.
Thanks for the tip.
in case you're only following via email as edits to posts don't get an email notification
Something I worked out only recently: on the subscription form 'All' doesn't really mean all, exactly as you point out. But you can tick 'edits' as well.
The only down side is that if you get individual emails there is no indication (that I have noticed) that a message is an edit. So, your original post, the edit, and reply all look the same (until you read the email of course). I have just ticked 'digest' to see what that looks like...
in case you're only following via email as edits to posts don't get an email notification
Something I worked out only recently: on the subscription form 'All' doesn't really mean all, exactly as you point out. But you can tick 'edits' as well.
The only down side is that if you get individual emails there is no indication (that I have noticed) that a message is an edit. So, your original post, the edit, and reply all look the same (until you read the email of course). 'digest' doesn't help because it only gives the subject line: I was expecting to see the message bodies, but just wrapped in a single email once a day.