[MTOS-dev] hAtom in MT 4.1

[Beau Smith]

+1  -  exactly the solution I would like to see. I'll create the  
following feature cases:

	- use author id when author nickname isn't specified
	- make nickname a required element for new and edited user accounts

_beau




On Jan 19, 2008, at 10:28 PM, Niall Kennedy wrote:

>
>   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