On 9-9-2015 16:31, Alex Peshkoff wrote: >>> FB3 supports use of multiple authentication plugins. It may happen (when >>> no encryption is used) that first one works at connect stage, next >>> starts at attach stage and later follows exchange with auth data until >>> authentication success (or failure). This saves roundtrips when attaching. >> Thanks for the explanation. This sort of things makes implementing an >> equivalent authentication mechanism a lot harder. I would very much have >> preferred a single mechanism (even though if they look and work >> similar). > > I've so many times read/heard about too slow firebird remote protocol > compared with other SQL servers that tried to save roundtrips when/where > possible ...
I am not specifically talking about saving packets. The assumptions and requirements of the new authentication protocol handshake are - as far as I know - not documented in structured manner except in the code itself. When I get it a bit cleaned up and working in Jaybird I'll do my best to add it to the existing wire protocol doc. For a non-C++ programmer the Firebird code can be a real maze when looking for where things are defined and how they are defined and how things go together (as an example: ClntAuthBlock is implemented partially in remote.cpp and interface.cpp); I need to keep switching between remote.cpp, interface.cpp, and inet.cpp (with occasional sidesteps to protocol.h and protocol.cpp) and at the same time juggling with a mental model of the Jaybird code and the Firebird code. The good thing is that with the changes and restructuring I made the last few days to the earlier pull request I received, the tests still work against Firebird 2.5, and against Firebird 3 with legacy auth, the tests against Firebird 3 now fail if I allow use of Srp (it looks like I made an error somewhere, or I can't get away with skipping support in the attach phase :(. >> For now I will look if I can get away with only having it in >> the connect stage. > > Client may skip sending any info at particular stage, server should just > start op_cont_auth exchange in that case. > Moreover - it can be forcely started by server before op_attach in a > case when line to be encrypted. This ensures sending DPB contents using > reliable encrypted connection, avoiding man-in-the-middle attacks on > DPB/SPB. All things that make it hard to map a mental model of the requirements of the protocol and write a compatible implementation. Sorry, I am venting, but I am a bit frustrated after spending the better part of two days to come to a stage where I have better structured code, while at the same time I broke the actual functionality I started out to improve (the Srp auth). Mark -- Mark Rotteveel ------------------------------------------------------------------------------ Monitor Your Dynamic Infrastructure at Any Scale With Datadog! Get real-time metrics from all of your servers, apps and tools in one place. SourceForge users - Click here to start your Free Trial of Datadog now! http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
