05.08.2016 18:18, Alex Peshkoff wrote:
> On 08/05/2016 07:01 PM, Dimitry Sibiryakov wrote:
>> 05.08.2016 17:48, Alex Peshkoff wrote:
>>> That's priority byte. If 2 different clumplets of data from auth block
>>> both map into same authentication type (role for example) but with
>>> different values
On 08/05/2016 07:13 PM, Dimitry Sibiryakov wrote:
> 05.08.2016 17:48, Alex Peshkoff wrote:
>> In the end of ClumpletReader.h you can find AuthReader class that helps
>> to parse auth block.
> I see the class but it gives me no idea how to interpret data from auth
> blocks. How can
> I understa
On 08/05/2016 07:01 PM, Dimitry Sibiryakov wrote:
> 05.08.2016 17:48, Alex Peshkoff wrote:
>> That's priority byte. If 2 different clumplets of data from auth block
>> both map into same authentication type (role for example) but with
>> different values wins one with higher priority (traditionally
05.08.2016 17:48, Alex Peshkoff wrote:
> In the end of ClumpletReader.h you can find AuthReader class that helps
> to parse auth block.
I see the class but it gives me no idea how to interpret data from auth
blocks. How can
I understand that this block is user name and that - password if ther
05.08.2016 17:48, Alex Peshkoff wrote:
> That's priority byte. If 2 different clumplets of data from auth block
> both map into same authentication type (role for example) but with
> different values wins one with higher priority (traditionally that means
> that numeric value of priority is lower).
On 08/05/2016 05:18 PM, Dimitry Sibiryakov wrote:
> Hello, All.
>
> I've dumped dpb and got following sequence:
>
> 79 - isc_dpb_auth_block, ok
> 90, 0, 0, 0 - its length is 90, ok, next 90 bytes is supposedly auth
> block itself in
> wide untagged format
> 0 - it must be auth
On 08/05/2016 04:28 PM, Dimitry Sibiryakov wrote:
> 05.08.2016 15:26, Alexander Peshkov (JIRA) wrote:
>> That's not improvement but step back compared with use of authentication
>> block in provider.
> In this case inconsistent transfer of auth parameters into a provider is
> a bug. Should
>
05.08.2016 17:39, Alex Peshkoff wrote:
> Yes, different types of connection
> transfer attachment parameters into a provider in different ways. That's
> as designed.
And how is a provider supposed to cope with all these different ways?
--
WBR, SD.
Hello, All.
I've dumped dpb and got following sequence:
79 - isc_dpb_auth_block, ok
90, 0, 0, 0 - its length is 90, ok, next 90 bytes is supposedly auth block
itself in
wide untagged format
0 - it must be auth tag, but 0 is not among them, WTF???
85, 0, 0, 0 - length of data 8
05.08.2016 15:26, Alexander Peshkov (JIRA) wrote:
> That's not improvement but step back compared with use of authentication
> block in provider.
In this case inconsistent transfer of auth parameters into a provider is a
bug. Should
I add another ticket?
--
WBR, SD.
---
Don't delete isc_dpb_user_name clumplet from remote connection dpb
--
Key: CORE-5323
URL: http://tracker.firebirdsql.org/browse/CORE-5323
Project: Firebird Core
Issue Type: Impr
11 matches
Mail list logo
