Bug 1) Images are not archived if linked to using BB code other than the form
http://website.url/whatever
.
http://website.url/whatever
and
http://website.url/whatever
do not work.
Bug 2) Previewing an edit to a wiki page causes an error message even though posting works.
[quote]An Error Has Occurred!
You aren’t allowed to modify just any post.
[/quote]
Bug #1; Just like the last mammoth must have thought: cannot reproduce. Everything works and I made two useless posts to prove it. You can see the images are stored on the JGO server. Only [IMG] (img tag with capitals) fails to be picked up, but shows up on your post as a direct reference to the original resource. Nobody uses [IMG] anyway.
In case you had a problem with image retrieval, it’s very likely that to access the image, you needed some cookie (like in gmail / attachments, or websites being strict about embedding images, verifying the referer in the http header) in that case, only you can view the image, so posting it on JGO will lead to a failure to download to the JGO server, just like everybody else would be unable to see your image.
As for Bug #2: known bug, reported before. I’m not sure I’m going to put much effort into it. Nobody but Roquen uses the wiki, and I hope he can live with this bug 
Websites like Imgur gives users the version with capital letters. So it might be a much more common occurrence.
All the images in this thread are not cached.
Additionally, while visiting this thread, I noticed your previous post no longer displays the archived version of resized images.
I’ve also seen quite a few instances of copy-pasted image links with capital letters besides Imgur.
Edit: Never mind. The resized images on this page work. The others did not link to the archived version. Now there’s not even an tag in the post I was talking about (with capitalized and non-capitalized IMG).
If you’re in the process of changing something, may I suggest making [img] case sensistive (and fall back to the plain text [ img ] blah blah [/ img]) and exclusively use the lower case version if making the archiver script case insensitive is too difficult.
Edit 2: missed the new post in the process of first editing
I changed the img-caching code today.
It was blasting through the allotted monthly datatraffic of my Linode VPS, and bandwidth isn’t cheap.
The whole goal of the img-caching was to prevent old images to vanish, so the new approach is this: upon posting, the images are fetched from the remote server, but the images will only be hosted from JGO after 2 months - by that time, the amount of required datatraffic should be only a fraction of what it was in the early days of the post. This approach allows me to continue securing the uploaded content, without paying hefty bills.
The spam protection is insane. It’s harder to people than to spammers. You can’t do the snippet in memory because of the hashCodes, meaning you have to go to a great length to solve it. Also the password restrictions are also insane - why do I need large letters in my password (which is already filled with numbers mixed with small letters) and why does it have to be 8 letters long? Right now I’m certain I will be using “I forgot my password” link anytime my browser forgets it… And it’s also hard to input such passwords (with capital letters) on mobile devices.
You can’t handle 8 character long passwords? :
Some sites require numbers, symbols, and capital letters.
The “remember my login” option lasts forever, or at least til you clear out cookies.
The spam protection is a pain, but so are spammers. Yet there’s still an active community here.
I have the opposite problem. I get angry when sites require fewer than X characters. (And unbelievably, it’s a financial institution I use that does this - where I want a long password the most!).
String hashCodes are easy. Read about them. They can be done with the help of Wikipedia and the calculator program that comes with most operating system distributions. See the thread about that topic.
Write down your password. It is seriously the most secure thing you can do. The trick is to put it where you keep your other valuable pieces of paper, such as your wallet (for frequently used websites) or a safe if you really need to store a password long term but don’t use it often (like an encryption key.) If you have to do that silly memorization thing, use a passphrase instead of a password.
Easy example, PayPal.
get this: the website of my ISP, yes my freaking ISP, only accepts user accounts with EXACTLY 8 characters, no more no less
How has no one brute forced it yet, especially with rainbow tables?
howsecureismypassword.net with test password @0XhrrP* (8 characters, with a number, symbol and upper/lower case) says 3 days 
Your main goal for website passwords is to stall an attacker long enough to find out your website was compromised and to respond to it. (Notify users, change passwords, and disable accounts.) You don’t always need long passwords. Unless you gain access to hashed passwords, you can only brute force a password as fast as the rate limiter allows it. If you had to give the password over the phone, could only guess a password once per day, and got a phonecall from the people that billed you if someone else tried to guess your password, then it’s not a problem.
A website is more automated, so it is harder to effectively rate limit people, easier to attack an account, and harder to reset passwords. You want tougher passwords because they could be guessed more often.
It depends on the usage of the password. It’s more of an omen of incompetence when you see maximum limits on password lengths because there is no technical reason for a limit if the website handled passwords correctly.
I use KeePass and store my password safe on dropbox where it’s replicated to three desktops, a laptop, a phone, and a tablet (soon to be two tablets). That ain’t getting lost.
I still live in fear that someday someone will get my gmail password and basically have the Keys To The Kingdom, since they could discover my other accounts and have my password reset sent there. I encrypt my phone now so at least getting my gmail password from that is not as easy, but the unlock is a real pain now, having to tap out a password instead of dragging out a pattern.
With one simple command, Dropbox can nuke that file on all devices simultaneously.
At the very least backup that file to a medium that is not active (like an unplugged usb drive)
Dropbox is convenient, not the ultimate savior of all my data for all time. Even with Dropbox’s poor security record, an attacker will get a very well encrypted database. Rubber Hose Decryption would be a far more successful strategy if you wanted to get my passwords.
Also, two of the desktops have regular backups, and I make semi-regular ones of the phone. The phone backup does go onto a thumb drive.
I meant you can accidentally send that command yourself. You don’t need a hacker to nuke a (distributed) file.
