On 18-11-2015 16:35, Alex Peshkoff wrote: > On 11/18/2015 02:09 PM, Mark Rotteveel wrote: >> I am still working with implementing the authentication for Firebird 3. >> And I want some one to document and describe the exact exchange of >> messages to me **without referring to the C++ code**, especially with >> regard to multiple authentication plugins and acceptance or reject of >> the authentication with that plugin. >> >> I thought I had it working, but just now I was writing a test that >> created a user with the Legacy_Usermanager, and I can only authenticate >> with that user if I disable Srp in Jaybird (by commenting out the >> Jaybird Srp plugin). The server returns isc_login in an op_response >> after the initial authentication step using Srp in op_connect, instead >> of an op_accept_data with instruction to switch plugins that I was >> expecting. >> >> This is becoming very frustrating, and when I look at the Firebird code >> I have the feeling of getting lost in a maze of twisty passages, and I >> am unable to find what I am doing wrong. > > Mark, your request about "the exact exchange" is close to unreal. > Exchange sequence highly depends upon plugins used, and inside plugins > it may also vary depending upon operating system. For example, in > windows trusted authentication nobody knows and it's not documented by > MS how many round-trips between client/server will be done. And > configuration parameters also affect exchange sequence - for example > with non-encrypted wire a portion of authentication information may be > sent to the server in attach packet (in DPB - that saves cclient/server > roundtrip), when encryption is used attach is sent after authentication > handshake is complete. > > Luckily to you, most of complexity is at the server side. > Client sends connect request and replies to continue_authentication > requests from server as long as it does not get response about > successful connection established, checking for received from server and > authentication plugin crypt keys and starting wire encryption when pair > key/plugin is found. At this moment (if appropriate flag is set) wire > compression should be started. After is attach/create/attach_service > request is send to server - at once again client should be ready to > check for continue_authentication requests from server. After receiving > success response attachment is established. That's all - but what about > detail messages sorry....
You don't seem to realise how hard it is to implement a protocol if you only have hard to follow source code available in a language you are not fluent in, and when some cases seem to work and others don't. I am seriously considering to quit developing Jaybird over this. Mark -- Mark Rotteveel ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
