QuickFixJ acceptor authentication

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

QuickFixJ acceptor authentication

Guido Medina
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi,

I wonder if there is an example where I can see an acceptor that authenticates the initiator via DB so that the session is NOT created if the authentication fails, also, any sender and target comp Id because the DB is what will tell if such session can be created.

I have been trying to dynamic sessions but somehow not working for QFJ 1.7.x (released internally)

Thanks a lot for any help, pointers/links, etc.

Guido.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: QuickFixJ acceptor authentication

Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi Guido,

here is an example how to define dynamic sessions:
http://www.quickfixj.org/quickfixj/usermanual/1.6.3/usage/acceptor_dynamic.html
We tested it with 1.7.x-SNAPSHOT without problems.

But I am not sure what you mean with your first sentence regarding authenticating an initiator via
the DB.

Cheers,
Chris.


On 29/01/17 21:53, Guido Medina wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> Hi,
>
> I wonder if there is an example where I can see an acceptor that authenticates the initiator via
> DB so that the session is NOT created if the authentication fails, also, any sender and target
> comp Id because the DB is what will tell if such session can be created.
>
> I have been trying to dynamic sessions but somehow not working for QFJ 1.7.x (released internally)
>
> Thanks a lot for any help, pointers/links, etc.
>
> Guido.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:[hidden email]
       


http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: QuickFixJ acceptor authentication

Guido Medina
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi Chris,

I was able to fix the dynamic sessions part of the equation but ApplicationExtended is not working as expected, the method canLogon(SessionID sessionID) is returning false and still the initiator is able to login.

I'm assuming such interface was created to intersect login actions in case you want to use user/password along with sender/target comp IDs

What am I missing? Here is my FixAcceptor and its caller:


final Config config;
final SocketAcceptor acceptor;

public FixAcceptor(Application application, Config config, String dataDictionary,
boolean needMessageStore, int port) throws ConfigError, FieldConvertError, SocketException {
this.config = config;

final SessionSettings settings = new SessionSettings();

// Standard settings:
settings.setString(SETTING_CONNECTION_TYPE, ACCEPTOR_CONNECTION_TYPE);
settings.setLong(SETTING_SOCKET_ACCEPT_PORT, port);
settings.setString(SETTING_START_DAY, "SUN");
settings.setString(SETTING_START_TIME, "17:00:00");
settings.setString(SETTING_END_DAY, "FRI");
settings.setString(SETTING_END_TIME, "17:00:00");
settings.setString(SETTING_TIMEZONE, "America/New_York");
settings.setLong(SETTING_HEARTBTINT, 30);
settings.setBool(SETTING_RESET_ON_LOGON, true);
settings.setString(SENDERCOMPID, WILDCARD);
settings.setString(TARGETCOMPID, WILDCARD);
settings.setBool(SETTING_USE_DATA_DICTIONARY, true);

// Disabled validations:
settings.setBool(SETTING_ALLOW_UNKNOWN_MSG_FIELDS, true);
settings.setBool(SETTING_VALIDATE_FIELDS_OUT_OF_ORDER, false);
settings.setBool(SETTING_VALIDATE_UNORDERED_GROUP_FIELDS, false);
settings.setBool(SETTING_VALIDATE_USER_DEFINED_FIELDS, false);
settings.setBool(SETTING_VALIDATE_INCOMING_MESSAGE, false);

// Default session settings:
final SessionID anySession = new SessionID(BEGINSTRING_FIX44, WILDCARD, WILDCARD);
settings.setBool(anySession, SETTING_ACCEPTOR_TEMPLATE, true);
settings.setString(anySession, BEGINSTRING, BEGINSTRING_FIX44);
settings.setString(anySession, SETTING_DATA_DICTIONARY, dataDictionary);

final SLF4JLogFactory logFactory = new SLF4JLogFactory(settings);
final MessageStoreFactory storeFactory;
if (needMessageStore) {
storeFactory = new MemoryStore.MemoryStoreFactory();
} else {
settings.setBool(SETTING_PERSIST_MESSAGES, false);
storeFactory = new NoopStoreFactory();
}

acceptor = new SocketAcceptor(application, storeFactory, settings, logFactory, MESSAGE_FACTORY);
acceptor.setSessionProvider(
new InetSocketAddress("0.0.0.0", port),
new DynamicAcceptorSessionProvider(settings, anySession, application, storeFactory, logFactory, MESSAGE_FACTORY)
);
}

public void start() throws ConfigError {
acceptor.start();
}

public void stop() {
acceptor.stop();
}
}
Its caller:


acceptor = new FixAcceptor(new ApplicationExtended() {
@Override
public void onCreate(SessionID sessionId) {
}

@Override
public void onLogon(SessionID sessionId) {
}

@Override
public void onLogout(SessionID sessionId) {
}

@Override
public void toAdmin(Message message, SessionID sessionId) {
}

@Override
public void fromAdmin(Message message, SessionID sessionId) throws FieldNotFound, IncorrectDataFormat, IncorrectTagValue, RejectLogon {
}

@Override
public void toApp(Message message, SessionID sessionId) throws DoNotSend {
}

@Override
public void fromApp(Message message, SessionID sessionId) throws FieldNotFound, IncorrectDataFormat, IncorrectTagValue, UnsupportedMessageType {
}

@Override
public boolean canLogon(SessionID sessionID) {
return false;
}

@Override
public void onBeforeSessionReset(SessionID sessionID) {
}
}
, config, someDictionary, true, somePort);
Best regards,

Guido.

On Mon, Jan 30, 2017 at 8:15 AM, Christoph John <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi Guido,

here is an example how to define dynamic sessions:
http://www.quickfixj.org/quickfixj/usermanual/1.6.3/usage/acceptor_dynamic.html
We tested it with 1.7.x-SNAPSHOT without problems.

But I am not sure what you mean with your first sentence regarding authenticating an initiator via
the DB.

Cheers,
Chris.


On 29/01/17 21:53, Guido Medina wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> Hi,
>
> I wonder if there is an example where I can see an acceptor that authenticates the initiator via
> DB so that the session is NOT created if the authentication fails, also, any sender and target
> comp Id because the DB is what will tell if such session can be created.
>
> I have been trying to dynamic sessions but somehow not working for QFJ 1.7.x (released internally)
>
> Thanks a lot for any help, pointers/links, etc.
>
> Guido.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Christoph John
Development & Support
Direct: <a href="tel:%2B49%20241%20557080-28" value="+4924155708028">+49 241 557080-28
Mailto:[hidden email]



http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: <a href="tel:%2B49%20241%20557080-0" value="+492415570800">+49 241 557080-0 | Fax: <a href="tel:%2B49%20241%20557080-10" value="+4924155708010">+49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: QuickFixJ acceptor authentication

Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Hi Guido,

canLogon() is only meant for initiators, if you wanted to suppress the Logon attempt that will be sent.
IMHO Username/Password authentication should take place in the admin callback.

Cheers,
Chris.


On 30/01/17 13:01, Guido Medina wrote:
Hi Chris,

I was able to fix the dynamic sessions part of the equation but ApplicationExtended is not working as expected, the method canLogon(SessionID sessionID) is returning false and still the initiator is able to login.

I'm assuming such interface was created to intersect login actions in case you want to use user/password along with sender/target comp IDs

What am I missing? Here is my FixAcceptor and its caller:

  final Config config;
  final SocketAcceptor acceptor;

  public FixAcceptor(Application application, Config config, String dataDictionary,
                     boolean needMessageStore, int port) throws ConfigError, FieldConvertError, SocketException {
    this.config = config;

    final SessionSettings settings = new SessionSettings();

    // Standard settings:
    settings.setString(SETTING_CONNECTION_TYPE, ACCEPTOR_CONNECTION_TYPE);
    settings.setLong(SETTING_SOCKET_ACCEPT_PORT, port);
    settings.setString(SETTING_START_DAY, "SUN");
    settings.setString(SETTING_START_TIME, "17:00:00");
    settings.setString(SETTING_END_DAY, "FRI");
    settings.setString(SETTING_END_TIME, "17:00:00");
    settings.setString(SETTING_TIMEZONE, "America/New_York");
    settings.setLong(SETTING_HEARTBTINT, 30);
    settings.setBool(SETTING_RESET_ON_LOGON, true);
    settings.setString(SENDERCOMPID, WILDCARD);
    settings.setString(TARGETCOMPID, WILDCARD);
    settings.setBool(SETTING_USE_DATA_DICTIONARY, true);

    // Disabled validations:
    settings.setBool(SETTING_ALLOW_UNKNOWN_MSG_FIELDS, true);
    settings.setBool(SETTING_VALIDATE_FIELDS_OUT_OF_ORDER, false);
    settings.setBool(SETTING_VALIDATE_UNORDERED_GROUP_FIELDS, false);
    settings.setBool(SETTING_VALIDATE_USER_DEFINED_FIELDS, false);
    settings.setBool(SETTING_VALIDATE_INCOMING_MESSAGE, false);

    // Default session settings:
    final SessionID anySession = new SessionID(BEGINSTRING_FIX44, WILDCARD, WILDCARD);
    settings.setBool(anySession, SETTING_ACCEPTOR_TEMPLATE, true);
    settings.setString(anySession, BEGINSTRING, BEGINSTRING_FIX44);
    settings.setString(anySession, SETTING_DATA_DICTIONARY, dataDictionary);

    final SLF4JLogFactory logFactory = new SLF4JLogFactory(settings);
    final MessageStoreFactory storeFactory;
    if (needMessageStore) {
      storeFactory = new MemoryStore.MemoryStoreFactory();
    } else {
      settings.setBool(SETTING_PERSIST_MESSAGES, false);
      storeFactory = new NoopStoreFactory();
    }

    acceptor = new SocketAcceptor(application, storeFactory, settings, logFactory, MESSAGE_FACTORY);
    acceptor.setSessionProvider(
      new InetSocketAddress("0.0.0.0", port),
      new DynamicAcceptorSessionProvider(settings, anySession, application, storeFactory, logFactory, MESSAGE_FACTORY)
    );
  }

  public void start() throws ConfigError {
    acceptor.start();
  }

  public void stop() {
    acceptor.stop();
  }
}
Its caller:


acceptor = new FixAcceptor(new ApplicationExtended() {
  @Override
  public void onCreate(SessionID sessionId) {
  }

  @Override
  public void onLogon(SessionID sessionId) {
  }

  @Override
  public void onLogout(SessionID sessionId) {
  }

  @Override
  public void toAdmin(Message message, SessionID sessionId) {
  }

  @Override
  public void fromAdmin(Message message, SessionID sessionId) throws FieldNotFound, IncorrectDataFormat, IncorrectTagValue, RejectLogon {
  }

  @Override
  public void toApp(Message message, SessionID sessionId) throws DoNotSend {
  }

  @Override
  public void fromApp(Message message, SessionID sessionId) throws FieldNotFound, IncorrectDataFormat, IncorrectTagValue, UnsupportedMessageType {
  }

  @Override
  public boolean canLogon(SessionID sessionID) {
    return false;
  }

  @Override
  public void onBeforeSessionReset(SessionID sessionID) {
  }
}, config, someDictionary, true, somePort);
Best regards,

Guido.

On Mon, Jan 30, 2017 at 8:15 AM, Christoph John <[hidden email]> wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J
Support: http://www.quickfixj.org/support/


Hi Guido,

here is an example how to define dynamic sessions:
http://www.quickfixj.org/quickfixj/usermanual/1.6.3/usage/acceptor_dynamic.html
We tested it with 1.7.x-SNAPSHOT without problems.

But I am not sure what you mean with your first sentence regarding authenticating an initiator via
the DB.

Cheers,
Chris.


On 29/01/17 21:53, Guido Medina wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> Hi,
>
> I wonder if there is an example where I can see an acceptor that authenticates the initiator via
> DB so that the session is NOT created if the authentication fails, also, any sender and target
> comp Id because the DB is what will tell if such session can be created.
>
> I have been trying to dynamic sessions but somehow not working for QFJ 1.7.x (released internally)
>
> Thanks a lot for any help, pointers/links, etc.
>
> Guido.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

--
Christoph John
Development & Support
Direct: <a moz-do-not-send="true" href="tel:%2B49%20241%20557080-28" value="+4924155708028">+49 241 557080-28
Mailto:[hidden email]



http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------
MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: <a moz-do-not-send="true" href="tel:%2B49%20241%20557080-0" value="+492415570800">+49 241 557080-0 | Fax: <a moz-do-not-send="true" href="tel:%2B49%20241%20557080-10" value="+4924155708010">+49 241 557080-10
         Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


--
Christoph John
Development & Support
Direct: +49 241 557080-28
Mailto:Christoph.John@...



http://www.macd.com


MACD GmbH
Oppenhoffallee 103
D-52066 Aachen
Tel: +49 241 557080-0 | Fax: +49 241 557080-10
 Amtsgericht Aachen: HRB 8151
Ust.-Id: DE 813021663

Geschäftsführer: George Macdonald


take care of the environment - print only if necessary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: QuickFixJ acceptor authentication

Colin DuPlantis
In reply to this post by Guido Medina
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



I don't have an example for 1.7, but this one works on 1.6.3.

public class DynamicAcceptorSessionProvider
        implements AcceptorSessionProvider
{
...
    @Override
    public Session getSession(SessionID inSessionId,
                              SessionConnector inConnector)
    {
        String sessionName = brokerService.getSessionName(inSessionId);
        // first, check to see if the session already exists
        Session session = Session.lookupSession(inSessionId);
        if(session != null) {
            return session;
        }
        // session doesn't exist yet, check to see if there's a session that matches in the DB
        FixSession fixSession = brokerService.findFixSessionBySessionId(inSessionId);
        if(fixSession == null) {
            return null;
        }
...
    }

I can't remember from the top of my head why/how returning null works. We have a list of preauthorized sessions in the db which we validate against.

Hope this helps.

- Colin

On 01/29/2017 12:53 PM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Hi,

I wonder if there is an example where I can see an acceptor that authenticates the initiator via DB so that the session is NOT created if the authentication fails, also, any sender and target comp Id because the DB is what will tell if such session can be created.

I have been trying to dynamic sessions but somehow not working for QFJ 1.7.x (released internally)

Thanks a lot for any help, pointers/links, etc.

Guido.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: QuickFixJ acceptor authentication

Guido Medina
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



Oh I see, you overwrite getSession (carefully) and return null, you will be disconnected automatically because session is not found.
Don't worry I understand how you would do it, I have seen the source code and contributed my bits to QFJ ;-)

Both ideas are good, I think it will be a matter of convenience on what to use: RejectLogon exception vs returning null.

Thanks a lot for the idea.

Guido.

On Mon, Jan 30, 2017 at 3:05 PM, Colin DuPlantis <[hidden email]> wrote:
QuickFIX/J Documentation: <a href="http://www.quickfixj.org/documentation/ QuickFIX/J" rel="noreferrer" target="_blank">http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/



I don't have an example for 1.7, but this one works on 1.6.3.

public class DynamicAcceptorSessionProvider
        implements AcceptorSessionProvider
{
...
    @Override
    public Session getSession(SessionID inSessionId,
                              SessionConnector inConnector)
    {
        String sessionName = brokerService.getSessionName(inSessionId);
        // first, check to see if the session already exists
        Session session = Session.lookupSession(inSessionId);
        if(session != null) {
            return session;
        }
        // session doesn't exist yet, check to see if there's a session that matches in the DB
        FixSession fixSession = brokerService.findFixSessionBySessionId(inSessionId);
        if(fixSession == null) {
            return null;
        }
...
    }

I can't remember from the top of my head why/how returning null works. We have a list of preauthorized sessions in the db which we validate against.

Hope this helps.

- Colin

On 01/29/2017 12:53 PM, Guido Medina wrote:
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/




Hi,

I wonder if there is an example where I can see an acceptor that authenticates the initiator via DB so that the session is NOT created if the authentication fails, also, any sender and target comp Id because the DB is what will tell if such session can be created.

I have been trying to dynamic sessions but somehow not working for QFJ 1.7.x (released internally)

Thanks a lot for any help, pointers/links, etc.

Guido.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users
Reply | Threaded
Open this post in threaded view
|

Re: QuickFixJ acceptor authentication

Christoph John
QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
QuickFIX/J Support: http://www.quickfixj.org/support/


Hi,

overwriting getSession and returning null is preferable if you want to just end the session without
sending a Logout. This might be desired in some cases.

 From FIXT spec:
-----------
When to send a Logout vs. when to just disconnect

In general a Logout message should always be sent prior to shutting down a connection. If the Logout
is being sent due to an error condition, the Text field of
the Logout should provide a descriptive reason, so that operational support of the remote FIX system
can diagnosis the problem. There are exceptions, when it is
recommended that a Logout message not be sent, these include:
• If during a logon either the SenderCompID, TargetCompID or IP address of the session initiator is
invalid, it is recommended that the session be
immediately terminated and no Logout message sent. This login attempt might be an unauthorized
attempt to break into your system; hence one does
not want to divulge any information about one’s FIX system, such as: which SenderCompID/TargetCompID
values are valid or which version of FIX is
supported.
• If during a Logon one receives a second connection attempt while a valid FIX session is already
underway for that same SenderCompID, it is
recommended that the session acceptor immediately terminate the second connection attempt and not
send a Logout message. Sending a Logout
message runs the risk of interfering with and possibly adversely affecting the current active FIX
connection. For example, in some FIX system
implementations, sending a Logout message might consume a sequence number that would cause an out of
sequence condition for the established FIX
session.

*In all other cases, if sending a Logout does not create risk or violate security, a Logout message
should be sent with a descriptive text message.*
-----------

Cheers,
Chris.

On 30/01/17 16:22, Guido Medina wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
>
> Oh I see, you overwrite getSession (carefully) and return null, you will be disconnected
> automatically because session is not found.
> Don't worry I understand how you would do it, I have seen the source code and contributed my bits
> to QFJ ;-)
>
> Both ideas are good, I think it will be a matter of convenience on what to use: RejectLogon
> exception vs returning null.
>
> Thanks a lot for the idea.
>
> Guido.
>
> On Mon, Jan 30, 2017 at 3:05 PM, Colin DuPlantis <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
>     QuickFIX/J <http://www.quickfixj.org/documentation/%0AQuickFIX/J> Support:
>     http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/>
>
>
>
>     I don't have an example for 1.7, but this one works on 1.6.3.
>
>     public class DynamicAcceptorSessionProvider
>             implements AcceptorSessionProvider
>     {
>     ...
>         @Override
>         public Session getSession(SessionID inSessionId,
>                                   SessionConnector inConnector)
>         {
>             String sessionName = brokerService.getSessionName(inSessionId);
>             // first, check to see if the session already exists
>             Session session = Session.lookupSession(inSessionId);
>             if(session != null) {
>                 return session;
>             }
>             // session doesn't exist yet, check to see if there's a session that matches in the DB
>             FixSession fixSession = brokerService.findFixSessionBySessionId(inSessionId);
>             if(fixSession == null) {
>                 return null;
>             }
>     ...
>         }
>
>     I can't remember from the top of my head why/how returning null works. We have a list of
>     preauthorized sessions in the db which we validate against.
>
>     Hope this helps.
>
>     - Colin
>
>     On 01/29/2017 12:53 PM, Guido Medina wrote:
>>     QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ <http://www.quickfixj.org/documentation/>
>>     QuickFIX/J Support:http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/>
>>
>>
>>     Hi,
>>     I wonder if there is an example where I can see an acceptor that authenticates the initiator
>>     via DB so that the session is NOT created if the authentication fails, also, any sender and
>>     target comp Id because the DB is what will tell if such session can be created.
>>     I have been trying to dynamic sessions but somehow not working for QFJ 1.7.x (released
>>     internally)
>>     Thanks a lot for any help, pointers/links, etc.
>>     Guido.
>>
>>     ------------------------------------------------------------------------------
>>     Check out the vibrant tech community on one of the world's most
>>     engaging tech sites, SlashDot.org!http://sdm.link/slashdot
>>
>>     _______________________________________________
>>     Quickfixj-users mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>>     <https://lists.sourceforge.net/lists/listinfo/quickfixj-users>
>     ------------------------------------------------------------------------------ Check out the
>     vibrant tech community on one of the world's most engaging tech sites, SlashDot.org!
>     http://sdm.link/slashdot _______________________________________________ Quickfixj-users
>     mailing list [hidden email]
>     <mailto:[hidden email]>
>     https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>     <https://lists.sourceforge.net/lists/listinfo/quickfixj-users>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
> _______________________________________________
> Quickfixj-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
--
Christoph John Development & Support Direct: +49 241 557080-28 Mailto:[hidden email]
http://www.macd.com <http://www.macd.com/>
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------
MACD GmbH Oppenhoffallee 103 D-52066 Aachen Tel: +49 241 557080-0 | Fax: +49 241 557080-10
  Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald
----------------------------------------------------------------------------------------------------
       
----------------------------------------------------------------------------------------------------

take care of the environment - print only if necessary

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Quickfixj-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfixj-users