Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Default
-
Resolution: Not a bug
-
Affects Version/s: 1.0.1
-
Fix Version/s: None
-
Component/s: Engine
-
Labels:None
-
Environment:Windows XP, Sun JVM 1.4.2_06
Description
Trying to reject invalid (potentially malicious) Logon requests from an unrecognised IP address fromAdmin by throwing RejectLogon exception when a "bad" Logon is detected.
The JavaDoc for RejectLogon says:
"This exception causes a logon to be reject with an immediate disconnect."
However Session.next(Message) is calling generateLogout() when RejectLogon is caught, so the disconnect is not "immediate", and the "unauthorized" logon attempt consumes a sequence number in the outgoing direction which the "authorized" connecting system may not be aware of when next it logs in, causing a ResendRequest to be sent when a valid logon is finally established (see FIX Protocol 4.4 with Errata 20030618, Vol 2 - "Session Protocol", page 6).
Attachments
Issue Links
- is related to
-
QFJ-45 When rejecting a logon, allow logout message to be optional before disconnect.
-
- Closed
-
Activity
The behavior is consistent with the C++ engine and the FIX spec so I'm reclassifying this issue as an improvement rather than a bug. However, I'll add the capability for the behavior to be optional. See the linked issue for more details.
OK, we can make that work, although you also might like to consider the inconsistency that then appears to occur when throwing RejectLogon if the Logout message is sent: the engine uses up a MsgSeqNum for its Logout, but doesn't appear to advance the sequence number it expects from the initiator.
I'll investigate this. I understand the issue with the consumed sequence number. However, on page 9 of the specification it states...
The only exception to the "do not terminate the session" rule is for an invalid
Logon attempt. The session acceptor has the right to send a Logout message
and terminate the session immediately. This minimizes the threat of
unauthorized connection attempts.
I'll check on the behavior of the C++ engine. I'd like to keep it consistent. In any case, the Javadocs should be updated to be more accurate.