June 21st, 2002

lung
  • ntang

"lj virus"

So people know, there's an "lj virus" now. It's just a bit of javascript that submits a new entry for you.

Here's the main page:

http://www.geocities.com/ljbuster2002/lj.html

Here's the actual page that adds the entry for you:

http://www.geocities.com/ljbuster2002/ljtest.html

Just make sure you have javascript turned off, or use wget or something to grab the actual source.

So, my question is: is it worth trying to block this sort of thing? Can we even block it, without blocking valid clients as well? Should we?
Collapse )
coding
  • mart

Patch: Make error messages nicer

This patch tidies up the output from some error messages LiveJournal produces due to URL types which different account types do not allow. In particular, they now all feature a link to the user's canonical journal URL (as suggested by andrewheadley), and have nicer HTML output, which I noticed needed to be done again thanks to andrewheadley.

It also makes bad arguments decline to Apache so that Apache can return its own "404 Not Found" message. My reasoning behind this is that I'm thinking about writing a generic "error handler" BML page which can pull in text from the translation system, and allowing Apache to supply the not found message means that if an ErrorDocument directive is present, it'll be used when the journal arguments are bad, thus giving a user the error in their preferred language.

Tested almost completely. User vanity domains were not tested because goathack's DNS settings don't allow them to work without a lot of messing around by me, and I've not changed the logic at all anyway so it should still work exactly the same as before aside from the HTML returned.

amused, happy
  • mart

The "don't" options

There are now two "Don't * comments" options for posting. These are "Don't allow comments" and "Don't send email notification of comments".

These assume a user is using the default of "Allow comments" and "Send email notification". These options should either just invert whatever setting the user already has or have sister options which do the opposite. The former has the disadvantage that a later switch of journal-wide settings would invert the one-off settings, which is probably not desireable, but the latter has the disadvantage that it requires client modifications, and it's pretty clear that client updates aren't as quick as they used to be now that there are many different clients and all are maintained by volunteers. (Most clients don't even support the new protocol version yet, which is a pretty vital change to make)

One of these two changes really should be implemented for the sake of symmetry, especially since right now there's no way to only enable email notifications for one specific entry, which would be quite a useful option until the full ESN system is in place.