[dev] Notifications and embedded hyperlinks

[Chuck Hagenbuch]

Quoting Jon Parise <jon at horde.org>:

> 1. Allow markup to be included in the existing notification messages.
>
>     This would involve removing htmlspecialchars() from the 'status'
>     listener.  An caller that might need the htmlspecialchars()
>     behavior will have to call it directly before the event is pushed
>     into the notification system.
>
>     Also, not all listeners may be able to handle embedded markup.

I'd veto this one.

> 2. Introduce a new parameter -- $flags -- to the Notification::push()
>    call.  A new NOTIFICATION_ALLOW_MARKUP flag will be introduced that
>    allow the listeners to "do the right thing" with the message text
>    when it comes time to render it.
>
>     This approach involves touching a lot of the Notification code.
>     It's a one-time hit because the $flags field is generic enough to
>     support additional flags in the future.  This will still result in
>     listener-specific behavior, however: some listeners may be able to
>     render the markup while others will just convert it to entities or
>     strip it out entirely.

I think we're going to have listener-specific behavior no matter what, and
that's okay, since that's the point of the different listeners. I mostly like
this one, but wish there was a way to do it without additional arguments.
However, this has the advantage that we are more explicitly controlling 
markup;
we sometimes pass user-provided data to these messages, so we need to 
make sure
that allowing links doesn't provide a way for someone to inject malicious
content.

> 3. Introduce a new notification type: horde.message.markup (or
>    something) that listeners can choose to handle.
>
>     This involves not changes to the Notification API.  The handlers
>     can be updated to support this new type individually.  Any
>     additional encoding is the responsibility of the caller.  The
>     downside is that, if the current listener chooses not to handle
>     this new type, the event will essentially be lost.

I don't like this for the reason Michael mentioned - this doesn't jive 
with the
kinds of messages that we have now. Also, potentially losing messages is Bad
(tm).

Jan's solution sounds good to me, but it seems like it'd be very hard to
validate the input to make sure that user-provided data didn't inject any
undesired markup/links.

-chuck

--
"Regard my poor demoralized mule!" - Juan Valdez