There really shouldn't be anything in created and opened unless you are
going to authenticate based on an IP address.
The authentication should be a part of your command message structure.
So you parse the commands into objects. Then you pass to the authentication
filter.
If message is of type authentication then do authentication else if
authenticated pass to the handler. If not authenticated and not type
authentication then close the session.
You only have two states. Authenticated or not.
On Aug 7, 2013 3:37 PM, "Hunter McMillen" <mcmil...@gmail.com> wrote:
> so all of the logic for the handler will basically be in messageReceived?
> And the state machine manages sessionCreated()/**sessionOpened()?
>
>
> Hunter
> On 8/7/2013 3:29 PM, Jon V. wrote:
>
>> That is basically how it is done.
>>
>> Io->packet processor->state machine->handler
>>
>> The state machine should only handle one packet at a time.
>>
>> In the message received just do...
>>
>> If ( authenticated )
>> Next filter.message received( msg )
>>
>> Else
>>
>> Etc
>> On Aug 7, 2013 3:22 PM, "Hunter McMillen" <mcmil...@gmail.com> wrote:
>>
>> So that is actually the solution we had before, but the state machine was
>>> in an authentication filter, we had a lot of trouble transitioning from
>>> "ok
>>> now I am done authenticating, I want to be in my IoHandler now"
>>>
>>> Hunter
>>> On 8/7/2013 3:03 PM, Jon wrote:
>>>
>>> So just implement some sort if authentication using the state machine
>>>> and
>>>> a database record lookup.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Aug 7, 2013, at 2:11 PM, Hunter McMillen <mcmil...@gmail.com> wrote:
>>>>
>>>> I misunderstood what you were asking, yes we have an abstract Command
>>>>
>>>>> class that has derivatives for all of the commands that a user could
>>>>> enter.
>>>>>
>>>>> Hunter
>>>>> On 8/7/2013 1:13 PM, Jon wrote:
>>>>>
>>>>> You must be building some sort of communication format for it.
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>> On Aug 7, 2013, at 1:06 PM, Hunter McMillen <mcmil...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> We're not really implementing a protocol, we are just trying to
>>>>>> make a
>>>>>>
>>>>>>> text-based game that will seamlessly support hundreds to thousands
>>>>>>> of users
>>>>>>> at a time.
>>>>>>>
>>>>>>> Hunter
>>>>>>> On 8/7/2013 12:02 PM, Jon wrote:
>>>>>>>
>>>>>>> This is more of a protocol implementation than a networking
>>>>>>>> question.
>>>>>>>> What kind of protocol are you implementing.
>>>>>>>>
>>>>>>>> Sent from my iPhone
>>>>>>>>
>>>>>>>> On Aug 7, 2013, at 11:34 AM, Hunter McMillen <mcmil...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> We actually won't need anything as complex as LDAP, just a simple
>>>>>>>> DB
>>>>>>>>
>>>>>>>>> hash + salt lookup.
>>>>>>>>>
>>>>>>>>> Hunter
>>>>>>>>> On 8/7/2013 10:26 AM, Emmanuel Lécharny wrote:
>>>>>>>>>
>>>>>>>>> Le 8/7/13 4:11 PM, Hunter McMillen a écrit :
>>>>>>>>>>
>>>>>>>>>> What are the common ways to authenticate users using Mina?
>>>>>>>>>>>
>>>>>>>>>>> The first attempt I made was using a state machine, but I had
>>>>>>>>>>> problems
>>>>>>>>>>> integrating that with an IoHandler.
>>>>>>>>>>>
>>>>>>>>>>> In retrospect, the state machine seems like overkill; so I was
>>>>>>>>>>> hoping
>>>>>>>>>>> to get ideas for other ways to authenticate users, or maybe a
>>>>>>>>>>> link
>>>>>>>>>>> to
>>>>>>>>>>> an application that does some authentication.
>>>>>>>>>>>
>>>>>>>>>>> would it be terrible to do something like this?
>>>>>>>>>>>
>>>>>>>>>>> public void sessionCreated(IoSession session) {
>>>>>>>>>>> authenticateUser() // < ----- Good idea? Bad Idea? Run in
>>>>>>>>>>> a
>>>>>>>>>>> separate thread?
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Depends...
>>>>>>>>>>
>>>>>>>>>> let's see how it works with LDAP :
>>>>>>>>>>
>>>>>>>>>> - the user can connect on the server (and the sessionCreated event
>>>>>>>>>> is
>>>>>>>>>> handled), but the user will not be authentified at this point.
>>>>>>>>>>
>>>>>>>>>> - in order to authenticate the user, we need to know about the
>>>>>>>>>> user.
>>>>>>>>>> Just having his IP address is certainly not good enough (it's easy
>>>>>>>>>> to
>>>>>>>>>> spoof it), so we expect the client to sent some credentials in the
>>>>>>>>>> first
>>>>>>>>>> dedicated message. In LDAP this is done through a BindRequest.
>>>>>>>>>> Anyway,
>>>>>>>>>> as you require the user to send you some data, you have to process
>>>>>>>>>> them
>>>>>>>>>> by handling the messageReceived event.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Last, not least : what about a separate thread ?
>>>>>>>>>>
>>>>>>>>>> That's a good question. The answer, again is "it depends". If it
>>>>>>>>>> takes
>>>>>>>>>> seconds to authenticat a user, because you have to send the auth
>>>>>>>>>> request
>>>>>>>>>> to a remote server, then having a separate thread for that sounds
>>>>>>>>>> smart.
>>>>>>>>>> Most of the time, the authent will take a few ms, and will be done
>>>>>>>>>> quite
>>>>>>>>>> rarely, so it's enough to execute this code in the same thread.
>>>>>>>>>>
>>>>>>>>>> Hope it helps.
>>>>>>>>>>
>>>>>>>>>>
>
