Allowing both SSL and non SSL connections

[kiropowered]

Hi,
I would like to handle non ssl connection to a specific port and ssl on another one, i also want both of them to handle dynamic sessions.
So I:

• I used 2 different implementations of AcceptorSessionProvider one for ssl and one for no ssl.
• Binded them to 2 different ports with method acceptor.setSessionProvider
• In the ssl provider I make sure to define the setting truststore
• I added 2 templates session as follow :

[session]
AcceptorTemplate=Y
BeginString=FIX.4.4
SocketAcceptPort=9877

[session]
AcceptorTemplate=Y
SocketUseSSL=Y
CipherSuites=TLS_RSA_WITH_AES_128_CBC_SHA
EnabledProtocols=TLSv1.2
SocketKeyStore=acceptor.keystore
SocketKeyStorePassword=password
NeedClientAuth=Y
BeginString=FIX.4.4
SocketAcceptPort=9878

It seems like the last definition override the first one and the app only listen to 9878 even thoI binded the 2 ports in acceptor.setSessionProvider.

Is it possible to have both ssl and non ssl ?

[chrjohn]

Hmm, did not really look into it, but maybe you might want to assign unique ports? In your config you assign 9877 twice...

[kiropowered]

Sry I just did an error when editing the ticket when I removed "sensitive" info but they are actually on different ports. I edited my original post. I think you can reproduce the issue with the config I mentioned and see that only the last definition is used.

Feels like when there is 2 times the same BeginString on a template only the last one is actually used

[the-thing]

@kiropowered Could you show the full configuration including the common section? You don't need to provide values for fields that expose some internal information, just key names e.g Key=

[kiropowered]

Sure this is the config,

`[default]
FileStorePath
ConnectionType=acceptor
SenderCompID=*
TargetCompID=*
StartTime=00:00:00
EndTime=00:00:00
FileLogPath=
RefreshOnLogon=Y
TestRequestDelayMultiplier=1
UseDataDictionary=Y
DataDictionary=dictionnary

JdbcDriver=com.mysql.cj.jdbc.Driver
JdbcURL=jdbc:mysql:
JdbcUser=
JdbcPassword=
JdbcLogHeartBeats=N
JdbcStoreMessagesTableName=
JdbcStoreSessionsTableName=
JdbcLogEventTable=
JdbcLogIncomingTable=
JdbcLogOutgoingTable=

[session]
AcceptorTemplate=Y
BeginString=FIX.4.4
SocketAcceptPort=9877

[session]
AcceptorTemplate=Y
SocketUseSSL=Y
CipherSuites=
EnabledProtocols=
SocketKeyStore=
SocketKeyStorePassword=
NeedClientAuth=Y
BeginString=FIX.4.4
SocketAcceptPort=9878
`

I also call of course 2 times with the corresponding ports 9877 and 9878, providing my custom acceptors
acceptor.setSessionProvider

But as I said it only listen to the last definition wich is 9878, if i switch position then it's the port 9877 that is used, but i never can get both to work

[kiropowered]

The whole idea behind using dynamic sessions is to not have to edit config files and restart the app to add/edit sessions.
Having both ssl/nossl mode available for our clients while let them choose if they want a secure connection or not(using the corresponding port).
Of course the CompID will be different from ssl to non ssl with a suffix like _SSL.

But as you can see even with different compids the test fail with AcceptorTemplate=Y on both session definition cause one override the other based on
BeginString=FIX.4.4
SenderCompID=*
TargetCompID=*

The only solution seems like to add SessionQualifier in one ofthem in order for the parser to actually listen to both ports.

So I am not sure to follow your solution

[chrjohn]

But as you can see even with different compids the test fail with AcceptorTemplate=Y on both session definition cause one override the other based on BeginString=FIX.4.4 SenderCompID=* TargetCompID=*

Using * on both sessions as CompIDs are no different CompIDs.
I meant that your config should look like this:

[default]
...
ConnectionType=acceptor
BeginString=FIX.4.4
...

[session]
AcceptorTemplate=Y
SenderCompID=A
TargetCompID=A
SocketAcceptPort=9877

[session]
AcceptorTemplate=Y
SenderCompID=B
TargetCompID=B
SocketAcceptPort=9878
... ssl settings and so on ...

Then do NOT use this constructor which defines one single template mapping with *

quickfixj/quickfixj-core/src/main/java/quickfix/mina/acceptor/DynamicAcceptorSessionProvider.java

Lines 97 to 102 in 8e25819

	public DynamicAcceptorSessionProvider(final SessionSettings settings,
	final SessionID templateID, quickfix.Application application,
	MessageStoreFactory messageStoreFactory, LogFactory logFactory,
	MessageFactory messageFactory) {
	this(settings, Collections.singletonList(new TemplateMapping(ANY_SESSION, templateID)),
	application, messageStoreFactory, logFactory, messageFactory);

Use this constructor which allows to pass different template mappings, in your case A and B:

quickfixj/quickfixj-core/src/main/java/quickfix/mina/acceptor/DynamicAcceptorSessionProvider.java

Lines 120 to 123 in 8e25819

	public DynamicAcceptorSessionProvider(final SessionSettings settings,
	List<TemplateMapping> templateMappings, quickfix.Application application,
	MessageStoreFactory messageStoreFactory, LogFactory logFactory,
	MessageFactory messageFactory) {

[kiropowered]

I actually don't use the DynamicAcceptorSessionProvider, I use a custom made one that look for sessions config in db.
That's what allow us to be fully dynamic and do some authorization so not any session is authorized and load keys if session are using ssl etc...

In your config file you set session with hardcoded values in SenderCompID and TargetCompID I still don't understand why

[chrjohn]

Then please show the code of your provider. Maybe in your branch.

Look at the code of DynamicAcceptorSessionProvider. It looks for the specified wildcard from the settings (be it A, B or *) and copies the settings from that template session to the newly created sessions. I suspect that you need something like that as well.
All that CompID=* stuff in the settings is only actually used by the DynamicAcceptorSessionProvider. If you don't use that provider it is pretty pointless to have * as CompIDs.

[kiropowered]

Ok so you advocate to use 2 differents compIds instead of using wildcard in both session with acceptorQualifier to have 2 listening socket.
Using wildcards look more appropriate in term of "configuration visualization" like it means "anything" usually.