Re: proposal: session server side variables

2017-01-03 13:03 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> Hello Pavel,
>
> PLEASE, could you remove the parts of emails you are not responding to
> when replying in the thread? THANKS.
>
> The current status is that both proposals are useless because the use case
>>>>> needs "some" transactional property for security. But probably some
>>>>> improvements are possible.
>>>>>
>>>>
>>>> Is there use case, when you would to play with transactions and
>>>> variables and RESET is not enough?
>>>>
>>>
>>> I do not know. If you explain more clearly what is meant by a "RESET" on
>>> a
>>> variable when the transaction fails, then maybe I can have an opinion.
>>> Currently I'm just guessing in the dark the precise intended semantics.
>>>
>>
>> reset can means "set to default"
>>
>
> "can"? The question is what does it mean in your proposal, not what it may
> mean. So I understand that it means "variable always reset to its default
> value at the end of the transaction".

yes

>
>
> Now when I though about it - this scenario is not interesting for PL -
>> probably can be interesting for some interactive work. In PL you can handle
>> transactions - so you know if was or was not any exceptions. And if you
>> didn't handle the exception, then you are in "need rollback state", so you
>> cannot to anything - look on variable value too. In PL is usually important
>> transaction start - difficult question if it can means subtransaction start
>> too.
>>
>
> What I understand from this use case variation is that the secure variable
> is expected to be set & used only *within* a single transaction, although
> across multiple functions typically called from some server-side PL-script,
> so that its value outside of the transaction does not matter wrt to
> security concerns. Did I understand?

When you are running under only one transaction, then you don't need to
solve reset variables on rollback, because you cannot do anything when
system fails. Only when you are handling a exception, then system continue,
and you can or you cannot to set the variable.

The usual scenario of using secure content is not related to transactions -
it is related to session.

There are two kind of functions

A. slow and expensive that creates secure content/context
B. other that use secure content/context

When you are running A, then some secure context is initialised or it is
invalided. When A fails, then B doesn't work. When A is successful, then
context is valid to another call of A. Next call of A set context or
invalidate context.

The transactions play nothing in this game.

The content of variable (used in PL) is defined by scope - not by
successful or unsuccessful transactions. The security content will be valid
although user have to do rollback.

>

> For this use-case, ISTM that the scope of the variable is necessarily the
> transaction, not the session, i.e. like using "set_config(..., TRUE)".
>
> --
> Fabien.
>