[dev] Notifications and embedded hyperlinks

[Jon Parise]

[Replying to Chuck's message, but incorporating everyone's feedback.]

On Thu, Mar 04, 2004 at 10:19:05AM -0500, Chuck Hagenbuch wrote:

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

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

As a compromise, I'd like to go ahead and add the $flags parameter.
Then, we could have the following flags:

    NOTIFICATION_RAW    - don't peform any encoding / conversions
    NOTIFICATION_WIKI   - perform Wiki-style translations
    ...

That will give us the flexibility to try different implementations in
the future without modifying the API.  Suggestions on better flag
names (or additional flags) are welcome.

-- 
Jon Parise (jon at horde.org) :: The Horde Project (http://horde.org/)