Log in

No account? Create an account
LiveJournal Development [entries|archive|friends|userinfo]
LiveJournal Development

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

January 29th, 2002

FIX: Check canonical username against reserved usernames [Jan. 29th, 2002|06:26 am]
LiveJournal Development



create.bml was comparing $FORM{'user'} against @LJ::PROTECTED_USERNAMES rather than $user, which has been shoved through LJ::canonical_username. The affect of this was that people could create lj_whatever by using hyphen instead of an underscore.

My patch fixes this by comparing against the canonicalised version instead.

I also rearranged the checks so that the "you must enter a username" thing can work on the canonicalised version, to reduce such oversights in the future. The canonical vs entered check had to go first because LJ::canonical_username returns an empty string if the username is invalid.

Simple stuff. I can't leave it running on my goathack because that machine will be in pain during the day tomorrow, I reckon. I'm sure you can see by the patch that it works, anyway... it's not exactly complicated.

link4 comments|post comment

Fixes to talk clusteration [Jan. 29th, 2002|07:35 am]
LiveJournal Development



These are actually just cosmetic fixes, really, which arise due to the way talklib supports two different kinds of URL.

To summarize what I wrote in the discussion on the news post about testing, it was returning a perl error when the journal parameter was the name of an unclustered user, and saying that the journal name could not be determined when using an old-style URL and the itemid doesn't exist.

My patch fixes this by firstly checking to see if, when the journal parameter is given, the user actually exists. If not, it sets a 'nosuchuser' flag and returns. If it does exist, it will check the clusterid for that user to see if they are actually clustered. If so, it proceeds as it did before, otherwise it drops out and lets the other bit of code deal with it.

This creates the illusion that the old-style sitewide itemid is working for that user temporarily. An alternative would be to set a flag saying "usernotclustered" and return, at which point the BML documents can note that. I thought it was nicer to pretend the URL was okay, but this does have the downside that the URLs will break in the future when the given user becomes clustered. I'm thinking that's okay so long as nothing ever links to the slightly iffy URL, just so that users can futz with URLs manually if they want.

The final thing it checks is if the old-style entry actually exists. If it doesn't, it again sets a flag and returns letting the BML page pick it up and print a correct error message.

It's been tested as extensively as I can on my unclustered goathack. I don't know how to configure clustering, and since we've currently got a massive black-box test going on anyway I figured it'd be alright to shove my code up there and see what happens. I've tested everything I can, and everything I've not tested in practice I've tested in theory... that is, I followed the code through myself and saw if what I was doing made sense. That's hardly foolproof, though.

linkpost comment

(no subject) [Jan. 29th, 2002|10:18 am]
LiveJournal Development


Was asked last night by the support people for a quick and easy way for people to look up overrides.
As a result i created this
I creates a new page that shows a user's overrides, linked on the see_request page, include a statement of weither or not a user has overrides already.
The main reason this was requested by #lj_support was that it would help to save time and pains of people having to look at a users source to help fix problems, Including the ability to see if the user has put the same override more then once.

It is currently referencing the user by its userid. It was brought up earlier that maybe we do not want to let people do that.

Comments Wanted

Tests & Examples:
http://lj.halkeye.net/support/see_request.bml?id=8 - user without override
http://lj.halkeye.net/support/see_request.bml?id=9 - User with override
link17 comments|post comment

Navcrap shouldn't show, if comments are off [Jan. 29th, 2002|03:23 pm]
LiveJournal Development


On talkread.bml, line 345, the navcrap is being displayed even if comments are disabled. I believe this shouldn't happen.

The 'patch'Collapse )
link4 comments|post comment

Bug? I can post to deleted community. [Jan. 29th, 2002|11:46 pm]
LiveJournal Development


I can post to a deleted community (namely developers). Is this a bug or a feature?

If it's a bug, I think in LJ::Protocol::postevent (around line 414) it should check if the community is deleted or suspended.

Something like this:

    ### allow for posting to journals that aren't yours (if you have permission)
    my $posterid = $u->{'userid'};
    my $ownerid = $flags->{'ownerid'};
+   ### disallow posting in deleted or suspended communities
+   return fail($err,XXX) if ($ownerid->{'statusvis'} eq "S" ||
+                             $ownerid->{'statusvis'} eq "D");
    # make the proper date format

Oops: $ownerid wouldn't work how I had it, but I'm sure you understand what I mean.
linkpost comment

[ viewing | January 29th, 2002 ]
[ go | Previous Day|Next Day ]