Log in

No account? Create an account
January 18th, 2004 - LiveJournal Development — LiveJournal [entries|archive|friends|userinfo]
LiveJournal Development

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

January 18th, 2004

S1 in C [Jan. 18th, 2004|11:50 pm]
LiveJournal Development





The 4 ways in Perl were:

-- via lots of regexps, like the old way.

-- with dynamically generated code blocks, one per template element






The experimental version of ljviews.pl is:


link2 comments|post comment

Rudimentary Offsite User Auth Mechanism [Jan. 18th, 2004|11:58 pm]
LiveJournal Development



There was a recent post about ways to validate if a given person is the LJ user they claim to be. One that intriegued me was temporarily adding a GUID to the interests list and then parsing the userinfo page. This leads me to the following proposal, which is a less hacky version of that.

The mechanism is simple, really. The external site provides the user with a link to a URL like http://www.livejournal.com/tools/auth_add.bml?token= followed by some identifier which is just an arbitrary string generated and stored by the originating site. LiveJournal will generate a page with a button to confirm the token and, if the user confirms, the token will be stored on the server related to the userid of the remote user.

The external site can also (optionally, I guess) provide a parameter for a URL to return to once the process is complete, which LiveJournal would link to and take the user back to the originating site.

There is then another URL which does not require a remote user which is called with a username and token and simply responds “YES” if the given token is stored for the given user, and “NO” if it is not. Presumably the URL supplied by the originating site above would cause the software at that site to request this URL and see if the token was added to the given account.

The above is the basic outline. It will probably end up being a little more complex than this, for example having the tokens expire after 30 minutes. Perhaps we could also allow the site to restrict the journaltype too so that they can require that only journaltype P can auth with them, although I suspect that would be a separate information-retrieval API rather than part of this system, since sites would probably want to validate that an account exists and is of a given type before they create the account on their system, rather than creating it and not letting it validate later.

The only real problem I see with this system is that LJ may get stuck supporting it even after something better comes along. However, I suspect the usual transitional period would be provided before this protocol was ditched after the advent of a superior system. It's got to be better than sites pulling down userinfo pages!

link15 comments|post comment

[ viewing | January 18th, 2004 ]
[ go | Previous Day|Next Day ]