Imported from previous forum
Whats the preferred method for handling
an invalid logon attempt ?
-
close the session ? (in this case no
error information can be given to the
client-) ) -
reject the logon and close the session
-
send a logout and close the session
Thank you for any help.
Patrick Aartsen.
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
The FIX 4.2 Specification is very clear on stating an authentication failure should result in closing the connection. Does anyone see a problem with providing a session level REJECT message that indicates authentication failure in the Text[58] field prior to closing the connection?
> > Whats the preferred method for handling
> > an invalid logon attempt ?
> >
> > - close the session ? (in this case no
> > error information can be given to the
> > client-) )
> >
> > - reject the logon and close the session
> >
> > - send a logout and close the session
> >
> >
> > Thank you for any help.
> >
> > Patrick Aartsen.
> >
> >
>
> Your choice #1 is the correct method. No reason is given to the initiator.
>
> According to the Fix 4.2 Specification and I quote (except for the stuff in parenthesis, which was added by me to add some context to the quoted information) :
> “If the authentication (of the session initiator’s logon message) fails, the session acceptor should shut down the connection.”
>
One thing to consider is that logon failure may be the result that the wrong party is attempting a connection.
If this is the case, you may want to:
- Not increment the incoming sequence number.
- Send a Logout or no message.
Not incrementing the incoming sequence number, will enable the proper party to still be able to connect. If you increment the number, when the proper party connects, the sequence number will be too low, and the connection will be dropped.
Sending a Logout or no messages, protects from erroneously resending a message to the proper party when they connect. If a reject was sent the previous connection, when the proper party connects, they will detect a sequence number too high, send a resend request, and then potentially recieve a reject that is not intended for them.
Note that the 4.2 spec on p.13 states "The administrative messages which are not to be resent are: Logon, Logout, ResendRequest, Heartbeat, TestRequest and SeqReset-Reset and SeqReset-GapFill. The SeqReset-GapFill can also be used to skip application messages that the sender chooses not to retransmit (e.g. aged orders). This leaves Reject as the only administrative message- which can be resent."
> The FIX 4.2 Specification is very clear on stating an authentication failure should result in closing the connection. Does anyone see a problem with providing a session level REJECT message that indicates authentication failure in the Text[58] field prior to closing the connection?
>
> > > Whats the preferred method for handling
> > > an invalid logon attempt ?
> > >
> > > - close the session ? (in this case no
> > > error information can be given to the
> > > client-) )
> > >
> > > - reject the logon and close the session
> > >
> > > - send a logout and close the session
> > >
> > >
> > > Thank you for any help.
> > >
> > > Patrick Aartsen.
> > >
> > >
> >
> > Your choice #1 is the correct method. No reason is given to the initiator.
> >
> > According to the Fix 4.2 Specification and I quote (except for the stuff in parenthesis, which was added by me to add some context to the quoted information) :
> > “If the authentication (of the session initiator’s logon message) fails, the session acceptor should shut down the connection.”
> >
>
[ original email was from Danny Shobrook - danny@aptcompsys.com ]
> Whats the preferred method for handling
> an invalid logon attempt ?
>
> - close the session ? (in this case no
> error information can be given to the
> client-) )
>
> - reject the logon and close the session
>
> - send a logout and close the session
>
>
> Thank you for any help.
>
> Patrick Aartsen.
>
>
I would have thought a logout with the authentication reason would be better than a session level reject as they do not seem to be monitored quite as much.