[buddypress-dev] Privacy component

[Beau Lebens]

As Isaac says, there isn't a universally-supported authentication  
mechanism for RSS/Atom feeds right now. Sad but true. TI wrote  
feedblendr.com and looked into it in depth and was frustrated to find  
nothing was supported across the board enough to bother with.  
Unfortunately it's not truly "solvable" right now, by us (/ 
BuddyPress), since obviously it'd require other clients to support it  
etc.

I've seen HTTP Basic, WSSE and obscurity-based authentication schemes  
in use mostly, and of those, obscurity (as you described Justin) was  
the simplest, most effective method. Obviously it's not super-secure,  
and if you use that, then you need a way to be able to "re-obscure"  
your URL as well in case it gets distributed somehow. HTTP Basic has  
*some* support in feed readers, more-so than WSSE.

HTH,

Beau

-- 
Beau Lebens
Dented Reality
dentedreality.com.au
beau at dentedreality.com.au

On Apr 15, 2008, at 3:55 PM, Justin Ball wrote:
> I think you are correct, but I think that the problem is important
> enough to solve.  One solution might be to use obscurity - append
> random tokens to the feed.  We aren't moving financial data around so
> it might be good enough.  Of course this isn't great .  Maybe HTTP
> Authentication could solve the problem?
>
> Justin
>
> On Tue, Apr 15, 2008 at 4:44 PM, Isaac Chapman
> <isaac.a.chapman at gmail.com> wrote:
>> RSS doesn't really support authentication in a standardized way  
>> across
>>  applications.  For all intents and purposes I would think the
>>  necessary filters ('posts_where' or 'query' if joining another table
>>  is required) would simply assume that any RSS requested content  
>> would
>>  be anonymous as the $current_user could not be set, and only return
>>  completely public content.
>>
>>> From my recollection Atom feeds do support a consistent  
>>> authentication
>>  mechanism, but it would be up to the user to enter their credentials
>>  in whatever client application/reader they were using.  As I doubt
>>  many people would do that, it would only show public content
>>  most of the time.
>>
>>  Isaac Chapman
>>
>>
>>
>>  On Tue, Apr 15, 2008 at 3:30 PM, Justin Ball  
>> <justinball at gmail.com> wrote:
>>> It would be great if there was some way to authenticate feeds so  
>>> that
>>>  I could see the posts my friend intends for me.  A first pass might
>>>  prevent anything other than public content from making it into  
>>> the RSS
>>>  feed, but later iterations should use some type of authentication
>>>  scheme.
>>>
>>>  Justin
>>>
>>>
>>>
>>>
>>>  On Tue, Apr 15, 2008 at 4:22 PM, Donnie La Curan  
>>> <don.lacuran at gmail.com> wrote:
>>>> Tags would work too.  Its just a matter of being able to link a  
>>>> friend
>>>> ("user") to that tag or group.  Then having those posts visible  
>>>> or not based
>>>> upon whether or not you are in that group.
>>>>
>>>> Another thing to think about as well would be the RSS feed.  How  
>>>> is the RSS
>>>> feed to know who you are and if you are in that friends list.  I  
>>>> guess just
>>>> not showing any posts with a "friend level criteria" would be a  
>>>> way to go.
>>>>
>>>>
>>>>
>>>> On Tue, Apr 15, 2008 at 3:30 PM, Chris Taylor -  
>>>> stillbreathing.co.uk
>>>> <chris at stillbreathing.co.uk> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Well, my initial thought was that people generally don't have a
>>>>> well-defined map in their heads of where their friends are on a  
>>>>> scale
>>>>> of privacy. OK, geeks do. But normal people may want to be able to
>>>>> just out their friends into arbitrary containers, without a
>>>>> pre-defined hierarchy. Tagging is perfect for this.
>>>>>
>>>>>
>>>>> On Tue, Apr 15, 2008 at 8:37 AM, Cass Edwards wrote:
>>>>>> How would the UI work for tagging and groups?
>>>>>
>>>>> Basically there would be a set of default tags which are  
>>>>> created when
>>>>> BP is installed. Things like "Friend", "Family" etc. These will be
>>>>> selectable using checkboxes when a friend is being added/ 
>>>>> edited. New
>>>>> tags will can also be entered in a textbox (comma-separated,  
>>>>> like post
>>>>> tags). New tags entered by the users will subsequently appear  
>>>>> next to
>>>>> the default tags with checkboxes.
>>>>>
>>>>> As long as the user keeps to less than approximately 20  
>>>>> distinct tags
>>>>> this will be fine. Any more than that and maybe a multi-select box
>>>>> would be better. So a user will effectively create their own  
>>>>> groups of
>>>>> friends by the tags they assign. And, of course, a single  
>>>>> friend might
>>>>> have multiple tags and crossover several groups. The queries to  
>>>>> check
>>>>> all this might and up a little bit complex, but hopefully to  
>>>>> the user
>>>>> it will be pretty obvious what to do.
>>>>>
>>>>> I'm currently building this into myJournal and hope to be  
>>>>> testing it
>>>>> tomorrow or Thursday.
>>>>>
>>>>> Of course, there's very probably a better way. So, any thoughts?
>>>>>
>>>>> Chris
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> buddypress-dev mailing list
>>>>> buddypress-dev at lists.automattic.com
>>>>> http://lists.automattic.com/mailman/listinfo/buddypress-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Donnie La Curan
>>>> _______________________________________________
>>>>  buddypress-dev mailing list
>>>>  buddypress-dev at lists.automattic.com
>>>>  http://lists.automattic.com/mailman/listinfo/buddypress-dev
>>>>
>>>>
>>>  _______________________________________________
>>>  buddypress-dev mailing list
>>>  buddypress-dev at lists.automattic.com
>>>  http://lists.automattic.com/mailman/listinfo/buddypress-dev
>>>
>>  _______________________________________________
>>  buddypress-dev mailing list
>>  buddypress-dev at lists.automattic.com
>>  http://lists.automattic.com/mailman/listinfo/buddypress-dev
>>
> _______________________________________________
> buddypress-dev mailing list
> buddypress-dev at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/buddypress-dev