<?xml version='1.0' encoding='utf-8' ?>
<!-- If you are running a bot please visit this policy page outlining rules you must respect. http://www.livejournal.com/bots/ -->
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/'>
<channel>
<title>LiveJournal Development</title>
<link>http://community.livejournal.com/lj_dev/</link>
<description>LiveJournal Development - LiveJournal.com</description>
<lastBuildDate>Tue, 18 Apr 2006 18:29:22 GMT</lastBuildDate>
<generator>LiveJournal / LiveJournal.com</generator>
<image>
<url>http://www.livejournal.com/userpic/42132/26901</url>
<title>LiveJournal Development</title>
<link>http://community.livejournal.com/lj_dev/</link>
<width>100</width>
<height>75</height>
</image>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/714037.html</guid>
<pubDate>Tue, 18 Apr 2006 18:29:22 GMT</pubDate>
<title>MogileFS - LJ - Replication</title>
<link>http://community.livejournal.com/lj_dev/714037.html</link>
<description>Got MogileFS up and running on a single test server running both mogstored and mogilefsd.<br />For test purposes instead of mounting different drives or partitions at /var/mogdata I just created three local directories dev1, dev2, dev3.<br /><br />When I create userpics, single copies of the pics are stored to /var/mogdata/dev1/0/000/000 - /var/mogdata/dev3/0/000/000. But it is only storing 1 copy of each userpic (mindevcount is set to 3 for userpics).<br /><br />Question - Is this working as designed because it is smart enough to realize that dev1-dev3 are really the same file system so why waist space?, or do I have something configured wrong that is preventing replication? (I did notice in the host table for hostid 1 the http_port set to 7500 but there is nothing in the http_get_port).<br /><br />Thanks.....</description>
<comments>http://community.livejournal.com/lj_dev/714037.html</comments>
</item>
<item>
<guid>http://community.livejournal.com/lj_dev/713810.html</guid>
<pubDate>Tue, 11 Apr 2006 17:25:28 GMT</pubDate>
<title>different ljconfig.pl for apache-ssl</title>
<link>http://community.livejournal.com/lj_dev/713810.html</link>
<description>Hi.<br /><br />I apologize if this is the wrong place for this post, but this is what I need to do.<br /><br />External access to our company's intranet is through https and through redirection. basically, from the internet, the user types in<br /><br /><a href="https://mycompany/blog">https://mycompany/blog</a> <br /><br />which the IIS server changes to<br /><br /><a href="https://blog/blog">https://blog/blog</a> (don't ask me why they have this setup) .. grabs the content and displays it to the outside user.<br /><br />so now, I am in a quandary.<br /><br />I want normal users (in the intranet) to be able to access <a href="http://blog">http://blog</a> and the users accessing from the extranet to be able to access <a href="https://blog/blog">https://blog/blog</a><br /><br />so what's the best way to do this?<br /><br />Here is what I have done so far.<br /><br />a) created a subdirectory (/home/lj/blog) and symlinked (/home/lj to /home/lj/blog) except ljconfig.pl<br />b) pointed /etc/apache-ssl/httpd.conf<br /> i) the document root to be /home/lj/blog <br /> ii) PERLSETEV LJHOME /home/lj/blog<br />c) changed /home/lj/blog/ljconfig.pl so that the $SITE variable is <a href="https://blog/blog">https://blog/blog</a><br /><br />basically what i want is that /home/lj be served by apache-perl and /home/lj/blog be served by apache-ssl <br /><br />when i try all this, unfortunately, I get the following error in /var/log/apache-ssl/error.log<br /><br />cannot find /home/lj/blog/htdocs/blog<br /><br />i must be making a stupid mistake.. but am i wrong in thinking the above will work?<br /><br />is there a better/easier way to do this? basically have 2 ljconfig.pl and make apache-perl read one and apache-ssl read the other?</description>
<comments>http://community.livejournal.com/lj_dev/713810.html</comments>
</item>
<item>
<guid isPermaLink='false'>http://community.livejournal.com/lj_dev/713549.html</guid>
<pubDate>Sun, 09 Apr 2006 16:58:17 GMT</pubDate>
<title>Interests API</title>
<link>http://community.livejournal.com/lj_dev/713549.html</link>
<description>Hi, I'm Israeli development consulter and working on some product that using LiveJournal.com API<br /><br />I'm not sure, that's right place to ask, but I'm seeking for "interests" API for LJ. The only information found was regarding set_interests(setinterests) and get_interests(getinterests) in changelogs. Maybe members of this community can point me to the right way to figure information regarding this interface<br /><br />Thank you</description>
<comments>http://community.livejournal.com/lj_dev/713549.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/713324.html</guid>
<pubDate>Sun, 09 Apr 2006 16:57:58 GMT</pubDate>
<title>One happy Dev machine?</title>
<link>http://community.livejournal.com/lj_dev/713324.html</link>
<description>The new userpic factory requires MogileFS in order to work and does not error out real gracefully if Mogilefs is not there. No biggey, I wanted to turn MogileFS on anyway. After reading up I think I see how to create the DB, create the storage devices, user mogadmin to populate the DB, set up the config files for mogstored and mogilefsd, start the daemons.<br /><br />The questions: Is there any hidden gotcha that will prevent this from all working on the same machine (obviously a dev env not a production env) if I set it up with only one storage device?<br /><br /><br />Thanks,</description>
<comments>http://community.livejournal.com/lj_dev/713324.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/713006.html</guid>
<pubDate>Fri, 07 Apr 2006 23:47:37 GMT</pubDate>
<title>subversion</title>
<link>http://community.livejournal.com/lj_dev/713006.html</link>
<description>We're now using Subversion instead of CVS. Everything's been imported into:<br /><br /><a href="http://code.sixapart.com/svn/livejournal/trunk/">http://code.sixapart.com/svn/livejourna<wbr />l/trunk/</a><br /><a href="http://code.sixapart.com/svn/ljcom/trunk/">http://code.sixapart.com/svn/ljcom/trun<wbr />k/</a><br /><br />And dozens of other repositories. (wcmtools was broken out into a repo per directory, pretty much, as each directory there was basically an old project....)<br /><br />But multicvs.pl (which the historical cvsreport.pl wraps) will take care of checking them all out. But for details, see:<br /><br /><a href="http://code.sixapart.com/svn/livejournal/trunk/cvs/multicvs.conf">http://code.sixapart.com/svn/livejourna<wbr />l/trunk/cvs/multicvs.conf</a><br /><br />Which has this list:<br /><br />SVN(livejournal) = <a href="http://code.sixapart.com/svn/livejournal/trunk/">http://code.sixapart.com/svn/livejourna<wbr />l/trunk/</a><br />SVN(gearman) = <a href="http://code.sixapart.com/svn/gearman/trunk/">http://code.sixapart.com/svn/gearman/tr<wbr />unk/</a><br />SVN(perlbal) = <a href="http://code.sixapart.com/svn/perlbal/trunk/">http://code.sixapart.com/svn/perlbal/tr<wbr />unk/</a><br />SVN(memcached) = <a href="http://code.sixapart.com/svn/memcached/trunk/">http://code.sixapart.com/svn/memcac<wbr />hed/trunk/</a><br />SVN(CSS-Cleaner) = <a href="http://code.sixapart.com/svn/CSS-Cleaner/trunk/">http://code.sixapart.com/svn/CSS-Cleane<wbr />r/trunk/</a><br />SVN(Sys-Syscall) = <a href="http://code.sixapart.com/svn/Sys-Syscall/trunk/">http://code.sixapart.com/svn/Sys-Syscal<wbr />l/trunk/</a><br />SVN(LWPx-ParanoidAgent) = <a href="http://code.sixapart.com/svn/LWPx-ParanoidAgent/trunk/">http://code.sixapart.com/svn/LWPx-Paran<wbr />oidAgent/trunk/</a><br />SVN(adengine) = <a href="http://code.sixapart.com/svn/adengine/trunk/">http://code.sixapart.com/svn/adengine/t<wbr />runk/</a><br />SVN(Danga-Socket) = <a href="http://code.sixapart.com/svn/Danga-Socket/trunk/">http://code.sixapart.com/svn/Danga-Sock<wbr />et/trunk/</a><br />SVN(djabberd) = <a href="http://code.sixapart.com/svn/djabberd/trunk/">http://code.sixapart.com/svn/djabberd/t<wbr />runk/</a><br />SVN(s2) = <a href="http://code.sixapart.com/svn/s2/trunk/">http://code.sixapart.com/svn/s2/trunk/</a><wbr /><br /><br />The machine has Trac and viewcvs installed as well. See <a href="http://code.sixapart.com/">http://code.sixapart.com/</a> which will soon be updated with more links/info.</description>
<comments>http://community.livejournal.com/lj_dev/713006.html</comments>
<category>multicvs</category>
<category>cvs</category>
<category>svn</category>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/712833.html</guid>
<pubDate>Wed, 05 Apr 2006 22:43:00 GMT</pubDate>
<title>Public Asterisk server</title>
<link>http://community.livejournal.com/lj_dev/712833.html</link>
<description>The public SIP/IAX2-to-LiveJournal <a href="http://community.livejournal.com/lj_dev/706430.html">project</a> has been finally resurrected.<br /><br />Try to do SIP/IAX2 to: <b>204.9.177.24</b><br /><br />And do a LJ voicepost. (if you have a paid account)<br /><br />The system is now outside of our network, but is using your LJ pin auth, and we're importing its recordings into LJ's network for posting to your journal.<br /><br />Please report success/failure with method/OS/client/etc.<br /><br />Thanks!<br /><br />P.S. It's known to work with <a href="http://iaxclient.sourceforge.net/iaxcomm/">iaxComm</a> on Win/Linux/Mac, but note that the iaxComm program is pretty flakey and the initial "Account settings" page is buggy, so you'll likely have to quit that screen and go back into preferences and re-add it. Username whatever ("guest" or blank), no password. Dial any number (say, "1"), then press "Dial" to connect.</description>
<comments>http://community.livejournal.com/lj_dev/712833.html</comments>
<category>asterisk</category>
<category>voicepost</category>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/712581.html</guid>
<pubDate>Mon, 03 Apr 2006 22:08:41 GMT</pubDate>
<title>LJ and PGP</title>
<link>http://community.livejournal.com/lj_dev/712581.html</link>
<description>I wonder if you have thought about it before.<br />Recently there was a case in the Russian livejournal community when someone set up a hoax account of a prominent person and used it to produce loads of silly comments in highly visible journals.<br />That made me wonder how to make sure that a hoax author can be easily identified. I didn't come to a complete solution of the problem, but it occurred to me that livejournal is a good implementation of a trusted peer network, and seems to be a good place to sign, exchange and use public keys. What do you think about this idea (as if you had nothing else to think about)?</description>
<comments>http://community.livejournal.com/lj_dev/712581.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/712356.html</guid>
<pubDate>Mon, 20 Mar 2006 06:33:17 GMT</pubDate>
<title>utf-8 bug</title>
<link>http://community.livejournal.com/lj_dev/712356.html</link>
<description>I'm sure there are more pressing bugs, but here's a note all the same.:<br /><br />Livejournal stores and transmits <strike>malformed</strike> illegal utf-8 characters such as the following: � (U+DBA0, a UTF-16 surrogate). This breaks clients and services that expect utf-8 replies, especially on xml which is usually more strict than html.</description>
<comments>http://community.livejournal.com/lj_dev/712356.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/712139.html</guid>
<pubDate>Wed, 15 Mar 2006 17:39:43 GMT</pubDate>
<title>BUG REPORT: Slight glitch with malformed tags.</title>
<link>http://community.livejournal.com/lj_dev/712139.html</link>
<description>I created a post with a tag that's just a "."<br /><br />LJ's tag system doesn't handle that condition as it should.<br /><br />Clicking on the . tag sends you to:<br /><br /><a href="http://m-leprae.livejournal.com/tag/">http://m-leprae.livejournal.com/tag/<wbr /></a><br /><br />It really ought to send you to:<br /><br /><a href="http://m-leprae.livejournal.com/tag/">http://m-leprae.livejournal.com/tag/<wbr /></a>.<br /><br />I guess that's not a legal URL however.<br /><br />A little more experimenting yields a few more glitches:<br /><br />Clicking on a tag that's .. will cause you to climb up to <a href="http://m-leprae.livejournal.com">http://m-leprae.livejournal.com</a><br /><br />Clicking on tag that's ../friends sends you to my friends page.<br /><br />Example entry at: <a href="http://m-leprae.livejournal.com/294364.html">http://m-leprae.livejournal.com/294<wbr />364.html</a><br /><br />There may be worse things one can do, but I'd rather not go there.</description>
<comments>http://community.livejournal.com/lj_dev/712139.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/711730.html</guid>
<pubDate>Fri, 10 Mar 2006 18:40:56 GMT</pubDate>
<title>Don't know where else to post this: Sprint picturemail fix</title>
<link>http://community.livejournal.com/lj_dev/711730.html</link>
<description>Cut in case it's off topic.<br /><a name="cutid1"></a><br /><br />Okay, so I use sprint, and their stupid method of emailing picture messages annoys me to no end. I otherwise like their service, and even if I didn't, we're married for the next two years anyhow :)<br /><br />Anyway, so I noticed with my samsung A900, I was posting pictures to livejournal and noticing they looked small and grainy. For a 1280x960 image, that didn't look right. It turns out that the actual image livejournal is posting is based on the xml crud in the email, which actually generates a small version of the image suitable for mobile phones. Ugh.<br /><br /><pre>
&lt;!-- lsPictureMail-Share-iETr4JPjm77BG8Bo7UHh-comment
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF&#45;8&quot;?&gt;
&lt;shareMessage&gt;
&lt;messageContents type=&quot;PICTURE&quot;&gt;
&lt;messageText&gt;Hi&lt;/messageText&gt;
&lt;mediaItems&gt;
&lt;mediaItem id=&quot;1&quot;&gt;
&lt;title&gt;&lt;/title&gt;
&amp;lt;url&amp;gt;http://pictures.sprintpcs.com/getMMBOXMessageMedia?id=Xw1004H8sLv6S3x76lVPYmsnJP2O20g3zlhB%2Fx7njqW9MscUXIEXBQmk5gW%2FZUWGmojEaNnHPws%2F%0A5lpklQ8%2Bufjui%2BAXcLyJG3ClZw2m2Gi1qkXdBdb5KgoH8KyzBNpwHmgReddy4aqnGyBYMpsPyA%3D%3D%0A&amp;lt;/url&amp;gt;
&lt;urlExpiration&gt;2006&#45;03&#45;10T19:31:51Z&lt;/urlExpiration&gt;
&lt;/mediaItem&gt;
&lt;/mediaItems&gt;
&lt;/messageContents&gt;
&lt;/shareMessage&gt;
--&gt;
&lt;!-- lsPictureMail-UserInfo-iETr4JPjm77BG8Bo7UHh-comment
&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF&#45;8&quot;?&gt;
&lt;UserInfo timestamp=&quot;2006&#45;03&#45;03T19:31:51.785+00:00&quot; originating_from_address=&quot;USERNAMEREDACTED@pm.sprint.com&quot;&gt;&lt;credential name=&quot;MDN&quot;&gt;248XXXXXXX&lt;/credential&gt;&lt;/UserInfo&gt;
--&gt;
</pre><br /><br />Ugly, huh?<br /><br />Anyway, there's some useful information, and the parser for this is at line 200 of livejournal/cgi-bin/ljemailgateway.pl.<br /><br />Now, I'm a perl ninja and all, but I really don't want to hack this deep into the code having never laid my hands on it before, and offer up a patch that will one day break, or not work right, so I'm hoping that if I supply a method of grabbing the full media file, someone else can make the fix and push it in? :)<br /><br /><br />Anyway, the key is in the actual body of the email, in the middle of the HTML. Yes, I know, parsing HTML to get this is fugly. Just wait, because it gets worse.<br /><br /><pre>
&lt;img src="http://pictures.sprintpcs.com//mmps/RECIPIENT/001_01116de4bcdbcd9c_1/2.2?inviteToken=iETr4JPjm77BG8Bo7UHh&amp;limitsize=258,258&amp;outquality=90&amp;squareoutput=255,255,255&amp;ext=.jpg&amp;iconifyVideo=true&amp;wm=1"/&gt;
</pre><br /><br />Okay, so there's the line from the email that has the actual image string we want in it. Here's what you have to do:<br /><br />Search the email for an image tag with the string "/mmps/RECIPIENT/" in the src.<br /><br />Pull out the url:<br /><a href="http://pictures.sprintpcs.com//mmps/RECIPIENT/001_01116de4bcdbcd9c_1/2.2?inviteToken=iETr4JPjm77BG8Bo7UHh&amp;limitsize=258,258&amp;outquality=90&amp;squareoutput=255,255,255&amp;ext=.jpg&amp;iconifyVideo=true&amp;wm=1">http://pictures.sprintpcs.com//mmps/REC<wbr />IPIENT/001_01116de4bcdbcd9c_1/2.2?invite<wbr />Token=iETr4JPjm77BG8Bo7UHh&amp;limitsize=258,2<wbr />58&amp;outquality=90&amp;squareoutput=255,255,25<wbr />5&amp;ext=.jpg&amp;iconifyVideo=true&amp;wm=1</a><br /><br />In the real email, they're actually HTML entities too, so you have to use HTML::Entities::decode_entities() to make it work right. It's already loaded (and used in the current code) so no biggie.<br /><br />What you have to end up doing is removing all arguments to that URL, except for inviteToken=blalbalbalblab and ext=.jpg<br /><br />So it now looks like:<br /><a href="http://pictures.sprintpcs.com//mmps/RECIPIENT/001_01116de4bcdbcd9c_1/2.2?inviteToken=iETr4JPjm77BG8Bo7UHh&amp;ext=.jpg">http://pictures.sprintpcs.com//mmps/REC<wbr />IPIENT/001_01116de4bcdbcd9c_1/2.2?invite<wbr />Token=iETr4JPjm77BG8Bo7UHh&amp;ext=.jpg</a><br /><br />This has the upside of removing the stupid "frame" from around the picture too. ugh.<br /><br />You now hold the raw media file, which in this example, is from my girlfriend's 640x480 phone, a picture of hello kitty.<br /><br />The upside to this URL, is also, strangely enough, that unlike the tag in the XML, this image does not expire. You can fetch it at any time, even if the mailserver is lagging bad, and doesn't process the message for the default expiry of 7 days.<br /><br /><br /><br />I'd be willing to pitch in what I can in terms of code to get this going, but from my description, it should be pretty self explanitory, and allow for much higher quality images to come from sprint phones.<br /><br />Thanks!</description>
<comments>http://community.livejournal.com/lj_dev/711730.html</comments>
<lj:mood>geeky</lj:mood>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/711461.html</guid>
<pubDate>Thu, 09 Mar 2006 10:58:17 GMT</pubDate>
<title>OpenId: wrongly escaped url?</title>
<link>http://community.livejournal.com/lj_dev/711461.html</link>
<description>Hey,<br /><br />Our users (<a href="http://www.foodcandy.com">http://www.foodcandy.com</a>) have issues with Lj's OpenId implementation on Firefox running on Linux. Details after the cut.<br /><a name="cutid1"></a><br />We redirect to something like this: <a href="http://www.livejournal.com:80/openid/server.bml?openid.identity=http%3a%2f%2fharryh.livejournal.com%2f&openid.return_to=http%3a%2f%www.foodcandy.com%2fAccountLogin.aspx&openid.trust_root=http%3a%2f%2fwww.foodcandy.com&openid.mode=checkid_setup&openid.assoc_handle=1141175386%3azLGZESEzvNsNz52O41kC%3a94aec3bf89">http://www.livejournal.com:80/openid/se<wbr />rver.bml?openid.identity=http%3a%2f%2fha<wbr />rryh.livejournal.com%2f&openid.return_to=http%3a%2f%www.foodcand<wbr />y.com%2fAccountLogin.aspx&openid.trust_root=http%3a%2f%2fwww.foodc<wbr />andy.com&openid.mode=checkid_setup&openid.assoc_handle=1141175386%3azLGZESE<wbr />zvNsNz52O41kC%3a94aec3bf89</a> - that seems to land at <a href="http://www.livejournal.com/openid/approve.bml?return_to=http://www.foodcandy.com/AccountLogin.aspx&identity=http://harryh.livejournal.com/&assoc_handle=1141175929:av40yQ946R3z4WrUd70P:42b4506fe8&trust_root=http://www.foodcandy.com">http://www.livejournal.com/openid/appro<wbr />ve.bml?return_to=http://www.foodcandy.co<wbr />m/AccountLogin.aspx&identity=http://harryh.livejournal.com/&assoc_handle=1141175929:av40yQ946R3z4WrU<wbr />d70P:42b4506fe8&trust_root=http://www.foodcandy.com</a>. <br /><br />Notice the unescaped parameters (looks wrong to me).<br /><br />My users are saying this is a blank page on firefox+linux.<br /><br />Ideas? Comments? Bug?<br /><br />Much appreciated,<br />dB.<br /></description>
<comments>http://community.livejournal.com/lj_dev/711461.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/711286.html</guid>
<pubDate>Tue, 07 Mar 2006 00:25:25 GMT</pubDate>
<title>XSS exploits & perm accounts</title>
<link>http://community.livejournal.com/lj_dev/711286.html</link>
<description>Another security bughunt round will begin soon (the code on both the live site and dev site needs to be updated), but before that begins I want to make sure everybody has their perm accounts.<br /><br />We notice that there are 9 people that haven't got theirs yet. If you're one, email accounts@livejournal.com (using the email you would've sent the XSS-LJ email with) with the username you want to have a perm account and we'll look up your ticket and award you.<br /><br />The SHA1s of the lowercased emails that still need perm accounts are:<br /><br />165ca37eabfd30d39c0b02063643fe2a73aa25d6<br />335410032e8c0c44a1c30f8f848ad0ac8a7e03c5<br />3f2c8af8ff061ccbe08494a62d714457d1a71c30<br />59e9914025681bb2145661c781d048b458880595<br />7457cb4526638c4304143688ed242a45847658d0<br />b619c73a32aa92ae6909cf9ec5b6c0bcbd481ba7<br />b87d5a97a2fce540e97edbc969d769f083b02f8d<br />cb5ae7ce9c253fd803a682a2816adc1fc692883e<br />d8c33159d760a5e5602728d9e52f7dbb9fa971e9</description>
<comments>http://community.livejournal.com/lj_dev/711286.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/711020.html</guid>
<pubDate>Mon, 27 Feb 2006 23:31:49 GMT</pubDate>
<title>Duplicate feeds for communities</title>
<link>http://community.livejournal.com/lj_dev/711020.html</link>
<description>Hello.<br />I'm product manager for Yandex Blog Search, russian blog search engine.<br /><br />We have some difficulties with LJ.<br /><br />Main difficulty now is that any community, for example, <a href="http://lj-dev.livejournal.com/">http://lj-dev.livejournal.com/</a> (and <a href="http://lj-dev.livejournal.com/data/rss">http://lj-dev.livejournal.com/data/rss</a><wbr />) is not a redirect to right location (<a href="http://community.livejournal.com/lj_dev/">http://community.livejournal.com/lj_de<wbr />v/</a>), but a duplicate. It leads to some side effects in our blog search.<br /><br />Do you think it is bug? We reported it first day after URLs changed, but it was not fixed.<br /><br />Sorry if this is wrong place for such questions.</description>
<comments>http://community.livejournal.com/lj_dev/711020.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/710896.html</guid>
<pubDate>Thu, 16 Feb 2006 17:00:34 GMT</pubDate>
<title>LJ Apache/mod_perl2 Port</title>
<link>http://community.livejournal.com/lj_dev/710896.html</link>
<description>Hello to everyone on ljdev!<br /><br />This is my first time post in ljdev although I've been monitoring ljdev on and off for many months now. I'm primarily interested in having a version of LJ running on Apache/mod_perl2 - finally getting around making it happen. Unfortunately I had to incorporate it as part of a school project to carve out the time.<br /><br />In a couple of weeks I hope to have semi-functioning LJ code that supports both Apache 1.x & 2.x and associated mod_perl (since that's when the project is due) - especially interested in having it run with minimal work with vanilla Fedora Core 4.<br /><br />There are a couple of ljdev posts regarding LJ and Apache 2.0 so there seems to be some interest. Will anyone be interested in my port? I'd like to contribute my work if anyone's willing to try it out.<br /><br />Advice and comments would be greatly appreciated!<br /><br />And finally I have some questions - some for the purposes of the port and others are for the project report (I have to get the school fluff out of the way!). A big thanks to those who reply!<br /><br /><ol><li>Why are you interested in a 2.x port? My initial motivation was to run a small private, LJ site for small group of friends but I couldn't get it to work with Fedora-out-of-the-box. My goal is to have LJ running with as little modification as possible to a Fedora system.</li><br /><li>For those who plan to install LJ on their own servers, how many users are you looking to support?</li><br /><li>What kind of systems are you planning to use as LJ server? OS? Desktop PC? Server machine?</li><br /><li>What are the primary reason(s) for using LJ? What kind of journals (work? personal?)</li><br /><li>Are you interested in a straight port to 2.x or one that supports both 1.x and 2.x?</li><br /><li>Why do you want backwards compatibility?</li><br /><li>What are you most worried about with installing/upgrading LJ?</li><br /><li>What part of the (LJ) installation process causes the most pain?</li><br /><li>What kind of configurations of LJ/Apache/mod_perl do you have?</li><br /><li>Additional comments/insights/suggestions? Any questions you think I should have asked?</li><br /></ol></description>
<comments>http://community.livejournal.com/lj_dev/710896.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/710503.html</guid>
<pubDate>Tue, 14 Feb 2006 18:09:27 GMT</pubDate>
<title>CVS repository down?</title>
<link>http://community.livejournal.com/lj_dev/710503.html</link>
<description>Hi,<br /><br />I'm new to livejournal, and would like to download the opensource for reference in my school project. However, I can't seem to be able to download anything through the cvs. Is the server currently down? If so, when will it be up again? Please advice, Thank you. :)<br /><br />Cheers.</description>
<comments>http://community.livejournal.com/lj_dev/710503.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/710161.html</guid>
<pubDate>Mon, 13 Feb 2006 19:53:25 GMT</pubDate>
<title>XSS update</title>
<link>http://community.livejournal.com/lj_dev/710161.html</link>
<description>Fixed a bunch, still got a handful to go.<br /><br />We're keeping all the emails in our ticket tracking system, and keeping track of who needs a permanent account. Ryan is going through the list this week (and some of last week) and emailing out perm account coupons/information.<br /><br />Will post more about round 3 when we're done fixing all current known issues.</description>
<comments>http://community.livejournal.com/lj_dev/710161.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/709783.html</guid>
<pubDate>Wed, 08 Feb 2006 05:02:41 GMT</pubDate>
<title>Enhancing the RTE</title>
<link>http://community.livejournal.com/lj_dev/709783.html</link>
<description>So I've been spending part of the day working on integrating <a href="http://www.fckeditor.net/">FCKeditor</a> into LJ, since we all know the current rich text editor isn't great. Issue I'm running into is it always converts &lt;, &gt;, and & to their html entities on submit. So this presents a problem for people wanting to type something like &lt;lj user='test' /&gt;.<br /><br />So two solutions I see:<br />A) Stop the entity conversion<br />B) Write a plugin that adds toolbar buttons for LJ specific tags<br /><br />Issue with A is that I can't figure out where the this conversion is happening. I have disabled the FCKConfig.ProcessHTMLEntities option, but a comment in fckhtmlentities.js says, "This entity is automatically handled by the XHTML parser". Every place it seems like it would be doing this conversion, it isn't. So frustrated with this option.<br /><br />Issue with B is I that can write a plugin to add a toolbar button with no problem, but don't think I can make it convert an lj tag when someone goes from normal to rich mode. Also not sure how to visually represent things like an lj-cut in the editing interface.<br /><br />Another option is to always convert the entity back on form submission, client or server side, this however would mean that I couldn't type the entities in the RTE like I did above as an example tag.<br /><br />So two solutions, neither of which seem perfect. Seems like the good solution is a combination of A and B, so a button to add these tags, and have them show up as a tag in the rich view while not being converted to entities on submit. Been reading through the project's site on SourceForge and seems like others have this same issue with entities; though I guess the project hasn't decided to address it yet. Costs $175 in a donation to get "email support". Anyone familiar with FCKeditor?<br /><br />Edit: Seems like I've just been going crazy with this all day and it is a fairly easy solution. On submit we do a bit of a onversion which should end up with the right stuff in the end. Sorry for the friends page spam. :P</description>
<comments>http://community.livejournal.com/lj_dev/709783.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/709562.html</guid>
<pubDate>Tue, 07 Feb 2006 21:29:41 GMT</pubDate>
<title>LJ crawler for reasearch purposes</title>
<link>http://community.livejournal.com/lj_dev/709562.html</link>
<description>Hello! I'm sure this has been asked many times, but I haven't found such a post looking back for a while. Anyway: I'm currently writing a crawler for LJ for a research project that I'm working on, and I want to make sure I'm following all the rules, and also if anyone has advice they could give me. <br /><br />First of all: the research is to determine group sentiment towards particular topics. We will make a single crawl over LJ and then use the data to develop agregate results. Details of individual users will not be mentioned in the report. <br /><br />For this project we plan to first seed our crawler with usernames and community names found in google searches on a particular topic. We will then crawl over community members and friends of users whose robots.txt files don't exclude crawlers. From each user we are considering only pulling the RSS file, or possibly pulling articles from up to a year in the past. <br /><br />I have a few questions, though:<br /><br /><ul><br /><li>What about pulling user comments? Would that be ok?</li><br /><li>How do I know if a community allows robots or not, since they don't have a subdomain with a robots.txt file?</li><br /><li>At what rate of requests/sec should I set my crawler to in order for it to be "nice"?</li><br /><li>Are there any previous simmilar works that anyone is aware of?</li><br /><li>For users that exclude robots: would it be appropriate if I send them a message via their livejournal email address asking if they would like to be included in the research?</li><br /></ul><br /><br />Again, this is strictly not for profit, aggregate data collection for research purposes only. I would appreciate any comments anyone has.</description>
<comments>http://community.livejournal.com/lj_dev/709562.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/709314.html</guid>
<pubDate>Tue, 07 Feb 2006 19:06:39 GMT</pubDate>
<title>An easier way to find CSS exploits</title>
<link>http://community.livejournal.com/lj_dev/709314.html</link>
<description>Another way to get permanent accounts, if nobody has beaten you to the exploit:<br /><br /><a href="http://www.test.dev.livejournal.org/misc/csstest.bml">http://www.test.dev.livejournal.org/mis<wbr />c/csstest.bml</a><br /><br />Find some CSS which does an alert box (or any JavaScript, but alerts are very in-your-face), then email me with at least subject "XSS-LJ <i>whatever</i>", the browser, and the CSS you put in the box.<br /><br />Happy Hacking.</description>
<comments>http://community.livejournal.com/lj_dev/709314.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/708866.html</guid>
<pubDate>Tue, 07 Feb 2006 00:06:07 GMT</pubDate>
<title>XSS contest, round 2</title>
<link>http://community.livejournal.com/lj_dev/708866.html</link>
<description>Same rules <a href="http://community.livejournal.com/lj_dev/708313.html">as before</a>. Try and inject JavaScript into the test server, now running newer code:<br /><br /><a href="http://www.test.dev.livejournal.org/">http://www.test.dev.livejournal.org/<wbr /></a><br /><br />Mail me if you find an exploit, and tell me which browser. Read the old post I linked for more details.<br /><br />Happy hacking!<br /><br /><b>BTW</b>, we're still tracking everybody's submissions. If you haven't gotten your permanent account, don't worry ... we haven't forgotten about you. Just backlogged.</description>
<comments>http://community.livejournal.com/lj_dev/708866.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/708810.html</guid>
<pubDate>Fri, 03 Feb 2006 06:55:07 GMT</pubDate>
<title>legacy cookie support actually fixed now</title>
<link>http://community.livejournal.com/lj_dev/708810.html</link>
<description>The code in LJ::Session which supported legacy cookie support was broken due to a subtle bug in BML's cookie handling. That's now fixed:<br /><br /><a href="http://community.livejournal.com/changelog/2656195.html">http://community.livejournal.com/change<wbr />log/2656195.html</a><br /><br />So all these issues will go away after the next code push:<br /><br /><a href="http://community.livejournal.com/lj_dev/706840.html">http://community.livejournal.com/lj<wbr />_dev/706840.html</a><br /><br />Sorry for not testing it last time... the code in LJ::Session was so simple it was "obviously" correct (and it was, afterall), but the BML bug messed it up. (that we got back [undef], not [], when ljmastersession wasn't present....)</description>
<comments>http://community.livejournal.com/lj_dev/708810.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/708425.html</guid>
<pubDate>Wed, 01 Feb 2006 05:01:23 GMT</pubDate>
<title>XSS challenge: update</title>
<link>http://community.livejournal.com/lj_dev/708425.html</link>
<description>Whoa, thanks everybody.<br /><br />Please, though, hold off on the XSS bug reports. We got way more than we thought. Embarassing. I was hoping for 5 or 6, not ~30.<br /><br />We've fixed most of them but still have a few hard ones remaining and most the incoming emails now are dups.<br /><br />Please wait for round two. (tomorrow or tomorrow night I'm guessing, after we update the test server's code...)<br /><br />Don't worry, we're making tickets for all of them, and we're keeping track of each ones who/what/when of them all. We'll be doing perm accounts in a batch after we put up round two.</description>
<comments>http://community.livejournal.com/lj_dev/708425.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/708313.html</guid>
<pubDate>Tue, 31 Jan 2006 06:29:46 GMT</pubDate>
<title>the XSS security challenge</title>
<link>http://community.livejournal.com/lj_dev/708313.html</link>
<description>Anybody bored and want a permanent account? Read on:<br /><br />We're going to be running an XSS (Cross site scripting / Javascript injection) bug hunt challenge soon here. The biz people like the idea but need to squabble over rules and legal stuff. <b>Unofficially</b>, it'll involve giving out permanent accounts and money (or gift certificates).<br /><br />So while I can't promise you jack right now in terms of money, I can give out permanent accounts like candy, so I'll announce the first round of the game:<br /><br /><b>STEP 1:</b> Go to <a href="http://www.test.dev.livejournal.org/">http://www.test.dev.livejournal.org/<wbr /></a> . Make an account. Probably need to <a href="http://www.test.dev.livejournal.org/admin/accounts/acctedit.bml">change it to paid</a> so you can make styles/etc.<br /><br /><b>STEP 2:</b> Inject some JavaScript. Use S1, S2, CSS, overrides, you name it. It'd probably help if you read the HTML and CSS cleaner code in cvs to look for bugs, but it's not required. If you want, the code is at:<br /><br />cvs/livejournal/cgi-bin/cleanhtml.pl<br />cvs/wcmtools/lib/HTMLCleaner.pm<br />cvs/wcmtools/lib/CSS-Cleaner/lib/CSS/Cle<wbr />aner.pm<br /><br />CVS viewers are at <a href="http://cvs.danga.com/">http://cvs.danga.com/</a> and <a href="http://cvs.livejournal.org/">http://cvs.livejournal.org/</a> .<br /><br /><b>STEP 3:</b> Email me (brad@danga.com) with subject containing at least "<b>XSS-LJ</b>", and a URL to a <b><i>minimal test case</i></b> illustrating your hole. I need to know how you did it, source code, maybe your test account's password, whatever it takes. The more clear it is, the more likely you win and I don't accept somebody else's later but more clear bug report first. After you find a hole, go create a new account for your next hole.<br /><br />Brad's unofficial rules: I am judge, jury, and sole candy giver, at least until there are official rules. If I give you a permanent account, that doesn't mean you're not eligible for money/gift certificates later. We'll retroactively give that out for the best/hardest-to-fix/most-clever holes after the fact.<br /><br /><b>NOTE:</b> The code running on the above URLs isn't live on the site yet. We don't care about holes at www.livejournal.com, because they're likely already fixed in the test code. The test code will go live on the site soon-ish. So reproduce (or produce) your bug reports on the test machine.<br /><br /><b>NOTE 2:</b> The test machine above is a small virtual machine. I might not have given it enough memory. If it sucks, I'll increase it. Bear with me.</description>
<comments>http://community.livejournal.com/lj_dev/708313.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/708069.html</guid>
<pubDate>Fri, 27 Jan 2006 00:38:18 GMT</pubDate>
<title>Discussing The Security Changes</title>
<link>http://community.livejournal.com/lj_dev/708069.html</link>
<description>As we announced last week in <span class='ljuser' style='white-space: nowrap;'><a href='http://news.livejournal.com/profile'><img src='http://stat.livejournal.com/img/newsinfo.gif' alt='[info]' width='16' height='16' style='vertical-align: bottom; border: 0;' /></a><a href='http://news.livejournal.com/'><b>news</b></a></span>, we have changed the canonical URL of most journal, community, and syndicated content. We have also now changed our cookie handling <a href="http://community.livejournal.com/lj_dev/706058.html">as Brad previously described</a>. In the end this means that it is much more difficult to steal a useful cookie. Our goal with our new cookie scheme is to limit the damage that can occur when your cookies do get stolen, which we're just going to assume is inevitable, as vulnerabilities have been found in all major browsers and we're quite sure new vulnerabilities will continue to be found.<br /><br />Shortly before our news post last week, we became aware that it was possible to use the “-moz-binding” CSS attribute within Mozilla and Mozilla Firefox to execute arbitrary offsite JavaScript. As this attribute is designed to allow attaching an XBL transform and JavaScript to any node within the DOM, it is quite easy to use in a malicious fashion. A <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=324253">bug</a> has also been filed in Mozilla's BugZilla tracker to try and address this issue. Over a year ago, <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=178993">we sponsored and developed</a> a patch for Mozilla to support HTTPOnly cookies which emerged in Internet Explorer 6 and would have prevented this attack, though this patch was never included in Mozilla.<br /><br />We immediately altered our cleaner to strip this attribute from entries and comments, though also realized that wasn't even half the battle. As we allow custom CSS in many of our styles, as well as the ability to link to an external stylesheet in a variety of fashions, it was quite possible to take advantage of this exploit and hijack the session cookie of any user who views your journal. As we, along with many other sites, used one cookie to authenticate a user, this cookie was quite powerful if stolen. If the user had not chosen to bind their cookie to their IP address, a malicious user could steal it, login as that user, deface the account and spam with it, as well as modify that user's style to include the exploit thus causing this problem to spread much like a virus.<br /><br />Borrowing the idea from another development team within Six Apart, we decided we needed to break our cookies into three categories. One cookie would be our master cookie, this cookie would only be accessible on www.livejournal.com where we will not display untrusted content. A second cookie will be accessible on all subdomains of livejournal.com, though it only will say if you are logged in or not; it is solely for optimization. We then will issue one cookie for each journal you visit. This cookie will be only accessible on username.livejournal.com or community.livejournal.com/username as it is limited to a single journal. This cookie will only grant you the permission to read protected entries and post in the particular journal. This means that if the journal owner steals your cookie, they will be able to do nothing more than view their journal as if they are you. In the end you will have n+2 cookies, with n being the number of journals you visit.<br /><br />Due to the fact that we cannot clean every external CSS stylesheet linked to every time we generate a journal page, this change is required. While it does not fully protect us from some new cross site scripting vulnerability that can be exploited via entries or comments, they are much easier to block, patch, and recover from quickly. With Mozilla deciding to allow the execution of arbitrary JavaScript via CSS, there is no other viable solution than the one we have undertaken.<br /><br />We've already taken a variety of steps to further protect your account such as we've <a href="http://www.livejournal.com/manage/logins.bml">implemented a page where you can see all of your login session</a>, now require your password to change your email address, and now send secure password reset emails. We also are planning future improvements, especially related to external CSS stylesheets, and hope everyone realizes the amount of attention we place on the security of every account. We're more than happy to answer any questions you have in regards to the changes we've made over the past week, though also hope it is understood that we are limited in what information we can share when actively dealing with a situation such as this.</description>
<comments>http://community.livejournal.com/lj_dev/708069.html</comments>
</item>
<item>
<guid isPermaLink='true'>http://community.livejournal.com/lj_dev/707830.html</guid>
<pubDate>Thu, 26 Jan 2006 17:43:10 GMT</pubDate>
<title>Apache2 + LJ fun</title>
<link>http://community.livejournal.com/lj_dev/707830.html</link>
<description>So, I decided to ignore the warnings about the LiveJournal code not working on Apache2 and try it anyway (using Apache2::compat for now). Oddly enough, some of the problems I've run into so far are mod_perl ones (I'm using 2.0.2) rather than LiveJournal ones...<br /><br /><ul><li>PerlSetEnv doesn't seem to have any effect in a VirtualHost, even though the docs say it should work (this is where <a href="http://community.livejournal.com/lj_dev/690668.html">someone else's attempts failed</a>). Moving it to global scope made it work. This would probably also apply if porting to mod_perl 2.0 properly.</li><li>Apache::LiveJournal::Interface::S2 - 'Bareword "OK" not allowed while "strict subs" in use', solved by changing the include to 'use Apache::Constants qw(NOT_FOUND OK);'. Not sure what causes this (but the change might still be necessary if porting properly)...</li><li>Apache2::compat <a href="http://perl.apache.org/docs/2.0/user/porting/compat.html#C_Apache__Constants_">"doesn't provide a complete back compatibility layer"</a> for Apache::Constants. BAD_REQUEST is missing (it's Apache2::Const::HTTP_BAD_REQUEST in mod_perl 2). This breaks FotoBilder.pm</li><li>Apache::Log and Apache::URI aren't provided by Apache2::compat, though their functionality is</li><li>Apache::compat doesn't work outside of Apache. update-db.pl indirectly depends on Apache::Constants. If anyone actually ports LJ, this should work properly.</li><br /><br />It still doesn't work (BML docs not handled, DocumentRoot not set, etc - IOW, the httpd.conf injection doesn't seem to work), though at least Apache starts now. I wonder how much work porting it to mod_perl 2 (rather than using Apache2::compat) would be?</ul></description>
<comments>http://community.livejournal.com/lj_dev/707830.html</comments>
</item>
</channel>
</rss>