[MTOS-dev] hAtom in MT 4.1

[Niall Kennedy]

   What we definitely have:
Author name
Author ID

   User John Smith logs on with username "johnjohn" which is also  
known as author ID #6. Displaying the logon name has negative security  
side-effects as we've now given a possible attacker the username part  
of the logon equation to help them focus their effort on brute-forcing  
a password. John could edit his profile and add a public-facing  
nickname, but this extra step is not required.

   Both the Atom Syndication Format and the hAtom microformat require  
defining an author for each entry with at least "a human-readable name  
for the person" authoring each entry.

   Given the current set of required MT author data in the current  
version of MT and the security concerns associated with revealing a  
user's logon to the public, our only current option is to use the  
author ID if we want to conform with the Atom Syndication Format spec.  
Consuming feed clients could at least correlate posts by author #6  
under this system.


Proposal:
   Movable Type author nicknames should be a required data element.  
This is consistent with MTEE's integration with LDAP (cn, or common  
name), and will allow us to better represent and protect an author's  
account information.

   New user creation flow might first present an author nickname and  
generate a recommended username from its value. A nickname entry of  
"John Smith" would auto-populate the username input field in much the  
same way an entry title pre-populates slug.

   Requiring at least a nickname for each user also ties in well with  
Movable Type's larger identity efforts.


-Niall Kennedy



On Jan 18, 2008, at 5:01 PM, Beau Smith wrote:

> Niall_
>
> Thanks for your review of the hAtom in MT default blog templates up  
> to spec. I can't guarantee that these changes will make it into 4.1,  
> but surely the the next update.
>
> Here's the current progress that has been committed to the  
> release-29 branch:
>
> categories.mtml
> - rel="tag" added
>
> tags.mtml
> - updated the function that creates the tag link to place the tag at  
> the end of the url, and thus left rel="tag" in the template.
>
> entry_metadata.mtml
> - parent vcard class removed
>
> One issue remains that stops us from being hAtom compliant:
>
> entry_metadata.mtml
> - We can not use the author's username or id as publishing this data  
> is a security vulnerability. Thus I'm unsure as to how we can comply  
> with the spec in this case.
>
> Suggestions:
>
> - Update MT to make Author Display Name a required field.
> - We could add an "About Widget" that included author info in hCard  
> format, but then this would require the user to edit this widget to  
> include their name and other contact info.
>
> Additional suggestions?
>
> _beau
>
>
>
>
> On Jan 16, 2008, at 11:34 PM, Niall Kennedy wrote:
>
>>  I added hAtom to my MT 4.01 blog last week. I took a look at the  
>> current MT 4.1 default templates and noticed a few areas that are  
>> not up to spec or otherwise in need of enhancement. Attached are my  
>> modifications to bring our default templates up to spec with hAtom.
>>
>> http://microformats.org/wiki/hatom#Format
>>
>>
>> entry_metadata.mtml
>> * vcard class is declared both inside and outside the conditional.  
>> should simply exist inside the conditional (line 4)
>> * entry is missing required "author" element if  
>> EntryAuthorDisplayName not present. Perhaps we could output the  
>> author ID to comply with the spec for this required element.
>>
>> categories.mtml
>> * Each category link should have rel=tag. parsers will grab the  
>> last part of the URL, meaning category basename by default.
>>
>> tags.mtml
>> * rel=tag implementation assigns the final part of the URL as a tag  
>> value, not the element value. The current implementation will  
>> result in a tag of mt-search scoped to tags and the current blog ID  
>> (mt-search.cgi?tag=politics&blog_id=1), and not the desired tag  
>> name. We might consider removing rel=tag here to prevent a search  
>> engine indexing this data and creating user headaches when they try  
>> viewing a tag list on another site.
>>
>>
>> -Niall Kennedy
>> http://www.niallkennedy.com/blog/
>>
>> < 
>> categories 
>> .mtml 
>> > 
>> < 
>> entry_metadata 
>> .mtml><tags.mtml>_______________________________________________
>> MTOS-dev mailing list
>> MTOS-dev at sixapart.com
>> http://www.sixapart.com/mailman/listinfo/mtos-dev