I had code in my init file that added an entry to auto-mode-alist for
oddmuse-mode. This resulted in oddmuse-mode being called twice. I'm
locally binding it to nil, now. I also used to call write-file at the
end of oddmuse-edit. This would change the buffer-name after I had
just changed it in oddmuse-mode. Now I'm using basic-save-buffer and
moved the call to oddmuse-mode to the end of oddmuse-edit.
Otherwise they blow up to full size.
95% value is arbitrary, maybe we can use calc() from CSS4 or provide a better
size for the surrounding container, hm.
$_ is not a copy, it is an alias to the original value.
Therefore modifying it will mess with original list... That's
not what we want most of the time.
Also, using map to s/// two variables does not look right. What
a stupid race to save one line of code.
Somehow the password form was limiting the number of characters to 50.
Private Wiki Extension relies on passwords that are 64 characters in length,
so I have increased the limit.
It was checking if the number of utf8 characters is <= 120, but obviously utf8
characters could be up to 4 bytes in length. 120*4 is much greater than 255
(which is a limit on lots of file systems), so it attempted to write files
with illegal filenames. This is now fixed.
Additionally $PageNameLimit option was added. Now you can choose max page
name length yourself (which is very useful for extensions like mac.pl or
private-wiki.pl)
These flags are essential for security. The problem we are trying to
solve is the following:
1) you visit a wiki using HTTPS and you set your password.
2) you accidentally visit the same website using plain HTTP
3) although you don't notice, your cookies are sent over the insecure
connection.
Even if that website has redirection, even it denies any insecure
traffic, your cookie is still leaked. That's how cookies work.
"secure" and "httponly" flags solve this. It means that these cookies
will only be sent over a secure connection. If you have set your
password using HTTPS and later you visit the same wiki using plain HTTP,
it will look like you are not logged in (because these cookies will not
be used when you access the website using a non-secure connection).
If you have HTTPS on your website -- ALWAYS make sure that you set your
password using it. Alternatively redirect all non-secure requests to
HTTPS - that's even better.
If you set your password using HTTP, the same cookie will be used for
both HTTP and HTTPS requests - this is done for compatibility with
HTTP-only wikis.
$ENV{'HTTPS'} returns 'on' or empty string. 'on' is truthy so it
should not create any problems, we can safely use it.
I've tested this, it works as expected.
