You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2010/01/09 01:05:02 UTC
About SslFilter.SESSION_SECURED
Hi,
while checking the SSL code, I found that we are injecting a
SslFilter.SESSION_SECURED message if some SslFilter.USE_NOTIFICATION is
true. This is just a String ("SESSION_SECURED"), and it's used nowhere.
If nobody can tell me about how usefull it is, I will remove all this
garbage. (IMO, this has been added a *long* time ago, back in oct 2005,
but it's not anymore necessary now. I don't even understand what it was
good for back then...).
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: About SslFilter.SESSION_SECURED
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 10, 2010, at 6:19 AM, Emmanuel Lcharny wrote:
> Alan D. Cabrera a écrit :
>>
>> On Jan 9, 2010, at 11:54 AM, Emmanuel Lecharny wrote:
>>
>>> Alan D. Cabrera a écrit :
>>>>
>>>> On Jan 8, 2010, at 4:05 PM, Emmanuel Lecharny wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> while checking the SSL code, I found that we are injecting a
>>>>> SslFilter.SESSION_SECURED message if some
>>>>> SslFilter.USE_NOTIFICATION is true. This is just a String
>>>>> ("SESSION_SECURED"), and it's used nowhere.
>>>>>
>>>>> If nobody can tell me about how usefull it is, I will remove all
>>>>> this garbage. (IMO, this has been added a *long* time ago, back
>>>>> in oct 2005, but it's not anymore necessary now. I don't even
>>>>> understand what it was good for back then...).
>>>>
>>>> I was talking to someone about this pattern in message stacks and
>>>> think that it's an anti-pattern. We debated for a while and I
>>>> think my point was taken with some reservations. Let me
>>>> elaborate on this anti-pattern and why it's bad.
>>>>
>>>> To my mind there are two ways to communicate events and
>>>> orchestrate behavior in this world of ours. First is using
>>>> interfaces to connect listeners with broadcasters. The other is
>>>> by sending actual "known" message objects up and down the message
>>>> stack. I believe that the latter is an anti-pattern since it
>>>> forces everyone to participate in the dispatching of the events,
>>>> most of whom one doesn't care about, and when there is an event
>>>> that is interesting in reality it is an event that's really part
>>>> of a lifecycle which, imo, should be an interface. The pattern
>>>> is also brittle in that if relies on flawless execution by all
>>>> members of the stack.
>>>>
>>>> The example of a need to send messages up the stack was the idle
>>>> event. IMO, this should not be in a library since it's an
>>>> application specific notion and it's quite possible that
>>>> participants in the stack may have a different notion as to what
>>>> constitutes an idle state.
>>>>
>>>> Maybe there are other examples where this pattern is compelling
>>>> but I cannot think of any.
>>>
>>> I partly agree with you. However, I see how a Filter can benefit
>>> from being informed about a specific message, such as the
>>> 'secured' one.
>>
>> Can you give a concrete example? Usually that would be a
>> communication between to connected filters not a general
>> notification to the entire stack.
> The problem is that filters don't necessary know that the filter
> they want to communicate with is present in the chain. A
> notification mechanism is much better, as the filter which need to
> be informed about a notification just have to be subscribed to such
> a notification (or to implement the method to catch this
> notification).
>
> A concrete exemple in our case (SslFilter) would be for the
> application to be able to know that the session is secured. I woudl
> not like my application to send a private key on he clear, or any
> private data, over a clear connection, for instance ! Of course, I
> can check if the session is secured in another way (pulling the info
> from the session attributes) but I don't think that it's a bad idea
> to send a specific message to the handler.
I'm hearing an application specific example, not an example where the
entire protocol stack needs to participate.
>>
>>> However (and you can check on another mail I wrote) I think that
>>> we may need to add a specific event for such a case, a
>>> notificationReceived() (and may be a notificationSend() : this
>>> could be used to inform the IoProcessor that the current session
>>> should be closed)
>>
>> Sorry, I'm not following, can you give a concrete example of what
>> you're thinking about?
> Right now, we just handle a few kind of events, like
> MessageReceived, MessageSent, SessionClosed, ExceptionCaught. I
> think that a notification like 'SessionSecured' could be valuable,
> instead of sending a String containing 'SECURED' in a
> MessageReceived event.
>
> Does it make sense ?
Ahh, ok, so "notificationReceived" is a generic notification.
Is MessageReceived, MessageSent in general use? It seems that they
would be but those events strike me as very application specific and
not cross cutting such as SessionClosed. For example, I could imagine
that for one message sent from the top of the stack many get created
downstream. So, with that in mind, Message sent/received really only
pertains to the top filter. It would be interesting to see if there
are counter examples.
Regards,
Alan
Re: About SslFilter.SESSION_SECURED
Posted by Emmanuel Lcharny <el...@gmail.com>.
Alan D. Cabrera a écrit :
>
> On Jan 9, 2010, at 11:54 AM, Emmanuel Lecharny wrote:
>
>> Alan D. Cabrera a écrit :
>>>
>>> On Jan 8, 2010, at 4:05 PM, Emmanuel Lecharny wrote:
>>>
>>>> Hi,
>>>>
>>>> while checking the SSL code, I found that we are injecting a
>>>> SslFilter.SESSION_SECURED message if some
>>>> SslFilter.USE_NOTIFICATION is true. This is just a String
>>>> ("SESSION_SECURED"), and it's used nowhere.
>>>>
>>>> If nobody can tell me about how usefull it is, I will remove all
>>>> this garbage. (IMO, this has been added a *long* time ago, back in
>>>> oct 2005, but it's not anymore necessary now. I don't even
>>>> understand what it was good for back then...).
>>>
>>> I was talking to someone about this pattern in message stacks and
>>> think that it's an anti-pattern. We debated for a while and I think
>>> my point was taken with some reservations. Let me elaborate on this
>>> anti-pattern and why it's bad.
>>>
>>> To my mind there are two ways to communicate events and orchestrate
>>> behavior in this world of ours. First is using interfaces to
>>> connect listeners with broadcasters. The other is by sending actual
>>> "known" message objects up and down the message stack. I believe
>>> that the latter is an anti-pattern since it forces everyone to
>>> participate in the dispatching of the events, most of whom one
>>> doesn't care about, and when there is an event that is interesting
>>> in reality it is an event that's really part of a lifecycle which,
>>> imo, should be an interface. The pattern is also brittle in that if
>>> relies on flawless execution by all members of the stack.
>>>
>>> The example of a need to send messages up the stack was the idle
>>> event. IMO, this should not be in a library since it's an
>>> application specific notion and it's quite possible that
>>> participants in the stack may have a different notion as to what
>>> constitutes an idle state.
>>>
>>> Maybe there are other examples where this pattern is compelling but
>>> I cannot think of any.
>>
>> I partly agree with you. However, I see how a Filter can benefit from
>> being informed about a specific message, such as the 'secured' one.
>
> Can you give a concrete example? Usually that would be a
> communication between to connected filters not a general notification
> to the entire stack.
The problem is that filters don't necessary know that the filter they
want to communicate with is present in the chain. A notification
mechanism is much better, as the filter which need to be informed about
a notification just have to be subscribed to such a notification (or to
implement the method to catch this notification).
A concrete exemple in our case (SslFilter) would be for the application
to be able to know that the session is secured. I woudl not like my
application to send a private key on he clear, or any private data, over
a clear connection, for instance ! Of course, I can check if the session
is secured in another way (pulling the info from the session attributes)
but I don't think that it's a bad idea to send a specific message to the
handler.
>
>> However (and you can check on another mail I wrote) I think that we
>> may need to add a specific event for such a case, a
>> notificationReceived() (and may be a notificationSend() : this could
>> be used to inform the IoProcessor that the current session should be
>> closed)
>
> Sorry, I'm not following, can you give a concrete example of what
> you're thinking about?
Right now, we just handle a few kind of events, like MessageReceived,
MessageSent, SessionClosed, ExceptionCaught. I think that a notification
like 'SessionSecured' could be valuable, instead of sending a String
containing 'SECURED' in a MessageReceived event.
Does it make sense ?
Re: About SslFilter.SESSION_SECURED
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 9, 2010, at 11:54 AM, Emmanuel Lecharny wrote:
> Alan D. Cabrera a écrit :
>>
>> On Jan 8, 2010, at 4:05 PM, Emmanuel Lecharny wrote:
>>
>>> Hi,
>>>
>>> while checking the SSL code, I found that we are injecting a
>>> SslFilter.SESSION_SECURED message if some
>>> SslFilter.USE_NOTIFICATION is true. This is just a String
>>> ("SESSION_SECURED"), and it's used nowhere.
>>>
>>> If nobody can tell me about how usefull it is, I will remove all
>>> this garbage. (IMO, this has been added a *long* time ago, back in
>>> oct 2005, but it's not anymore necessary now. I don't even
>>> understand what it was good for back then...).
>>
>> I was talking to someone about this pattern in message stacks and
>> think that it's an anti-pattern. We debated for a while and I
>> think my point was taken with some reservations. Let me elaborate
>> on this anti-pattern and why it's bad.
>>
>> To my mind there are two ways to communicate events and orchestrate
>> behavior in this world of ours. First is using interfaces to
>> connect listeners with broadcasters. The other is by sending
>> actual "known" message objects up and down the message stack. I
>> believe that the latter is an anti-pattern since it forces everyone
>> to participate in the dispatching of the events, most of whom one
>> doesn't care about, and when there is an event that is interesting
>> in reality it is an event that's really part of a lifecycle which,
>> imo, should be an interface. The pattern is also brittle in that
>> if relies on flawless execution by all members of the stack.
>>
>> The example of a need to send messages up the stack was the idle
>> event. IMO, this should not be in a library since it's an
>> application specific notion and it's quite possible that
>> participants in the stack may have a different notion as to what
>> constitutes an idle state.
>>
>> Maybe there are other examples where this pattern is compelling but
>> I cannot think of any.
>
> I partly agree with you. However, I see how a Filter can benefit
> from being informed about a specific message, such as the 'secured'
> one.
Can you give a concrete example? Usually that would be a
communication between to connected filters not a general notification
to the entire stack.
> However (and you can check on another mail I wrote) I think that we
> may need to add a specific event for such a case, a
> notificationReceived() (and may be a notificationSend() : this
> could be used to inform the IoProcessor that the current session
> should be closed)
Sorry, I'm not following, can you give a concrete example of what
you're thinking about?
Regards,
Alan
Re: About SslFilter.SESSION_SECURED
Posted by Emmanuel Lecharny <el...@gmail.com>.
Alan D. Cabrera a écrit :
>
> On Jan 8, 2010, at 4:05 PM, Emmanuel Lecharny wrote:
>
>> Hi,
>>
>> while checking the SSL code, I found that we are injecting a
>> SslFilter.SESSION_SECURED message if some SslFilter.USE_NOTIFICATION
>> is true. This is just a String ("SESSION_SECURED"), and it's used
>> nowhere.
>>
>> If nobody can tell me about how usefull it is, I will remove all this
>> garbage. (IMO, this has been added a *long* time ago, back in oct
>> 2005, but it's not anymore necessary now. I don't even understand
>> what it was good for back then...).
>
> I was talking to someone about this pattern in message stacks and
> think that it's an anti-pattern. We debated for a while and I think
> my point was taken with some reservations. Let me elaborate on this
> anti-pattern and why it's bad.
>
> To my mind there are two ways to communicate events and orchestrate
> behavior in this world of ours. First is using interfaces to connect
> listeners with broadcasters. The other is by sending actual "known"
> message objects up and down the message stack. I believe that the
> latter is an anti-pattern since it forces everyone to participate in
> the dispatching of the events, most of whom one doesn't care about,
> and when there is an event that is interesting in reality it is an
> event that's really part of a lifecycle which, imo, should be an
> interface. The pattern is also brittle in that if relies on flawless
> execution by all members of the stack.
>
> The example of a need to send messages up the stack was the idle
> event. IMO, this should not be in a library since it's an application
> specific notion and it's quite possible that participants in the stack
> may have a different notion as to what constitutes an idle state.
>
> Maybe there are other examples where this pattern is compelling but I
> cannot think of any.
I partly agree with you. However, I see how a Filter can benefit from
being informed about a specific message, such as the 'secured' one.
However (and you can check on another mail I wrote) I think that we may
need to add a specific event for such a case, a notificationReceived()
(and may be a notificationSend() : this could be used to inform the
IoProcessor that the current session should be closed)
Also we can't remove this SECURED message from MINA 2.0, as some of our
users may expecting to receive it, and it would be diruptive. In MINA
3.0, that's another question...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Re: About SslFilter.SESSION_SECURED
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 8, 2010, at 4:05 PM, Emmanuel Lecharny wrote:
> Hi,
>
> while checking the SSL code, I found that we are injecting a
> SslFilter.SESSION_SECURED message if some SslFilter.USE_NOTIFICATION
> is true. This is just a String ("SESSION_SECURED"), and it's used
> nowhere.
>
> If nobody can tell me about how usefull it is, I will remove all
> this garbage. (IMO, this has been added a *long* time ago, back in
> oct 2005, but it's not anymore necessary now. I don't even
> understand what it was good for back then...).
I was talking to someone about this pattern in message stacks and
think that it's an anti-pattern. We debated for a while and I think
my point was taken with some reservations. Let me elaborate on this
anti-pattern and why it's bad.
To my mind there are two ways to communicate events and orchestrate
behavior in this world of ours. First is using interfaces to connect
listeners with broadcasters. The other is by sending actual "known"
message objects up and down the message stack. I believe that the
latter is an anti-pattern since it forces everyone to participate in
the dispatching of the events, most of whom one doesn't care about,
and when there is an event that is interesting in reality it is an
event that's really part of a lifecycle which, imo, should be an
interface. The pattern is also brittle in that if relies on flawless
execution by all members of the stack.
The example of a need to send messages up the stack was the idle
event. IMO, this should not be in a library since it's an application
specific notion and it's quite possible that participants in the stack
may have a different notion as to what constitutes an idle state.
Maybe there are other examples where this pattern is compelling but I
cannot think of any.
Regards,
Alan
Re: About SslFilter.SESSION_SECURED
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 9, 2010, at 5:48 AM, Ashish wrote:
> On Sat, Jan 9, 2010 at 5:35 AM, Emmanuel Lecharny
> <el...@gmail.com> wrote:
>> Hi,
>>
>> while checking the SSL code, I found that we are injecting a
>> SslFilter.SESSION_SECURED message if some
>> SslFilter.USE_NOTIFICATION is
>> true. This is just a String ("SESSION_SECURED"), and it's used
>> nowhere.
>>
>> If nobody can tell me about how usefull it is, I will remove all this
>> garbage. (IMO, this has been added a *long* time ago, back in oct
>> 2005, but
>> it's not anymore necessary now. I don't even understand what it was
>> good for
>> back then...).
>
> As far as I can think, this is a way for the application to react in
> case a Secure session goes unsecure or vise-versa.
> Don't think I can decode the beyond that.
>
> Anyone using SSL Filter?
I am for HTTP but am happy to discuss it's demise if I can still get
the functionality that I need; see the other thread about filter house
cleaning.
Regards,
Alan
Re: About SslFilter.SESSION_SECURED
Posted by Ashish <pa...@gmail.com>.
On Sat, Jan 9, 2010 at 5:35 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi,
>
> while checking the SSL code, I found that we are injecting a
> SslFilter.SESSION_SECURED message if some SslFilter.USE_NOTIFICATION is
> true. This is just a String ("SESSION_SECURED"), and it's used nowhere.
>
> If nobody can tell me about how usefull it is, I will remove all this
> garbage. (IMO, this has been added a *long* time ago, back in oct 2005, but
> it's not anymore necessary now. I don't even understand what it was good for
> back then...).
As far as I can think, this is a way for the application to react in
case a Secure session goes unsecure or vise-versa.
Don't think I can decode the beyond that.
Anyone using SSL Filter?
--
thanks
ashish