Redirection parameter in firebird.conf

[Alex Peshkoff]

What about clean-up of this parameter?

I ask cause currently it's almost broken by logic of plugins like SRP
but still can play bad jokes from security POV (when for example trusted
auth is in use) and causes problems in
https://github.com/FirebirdSQL/firebird/issues/7579 fix. That problems
are solvable, moreover currently solved in a branch - but why pollute
code in order to support almost broken, dangerous and in generic useless
feature?

[Dimitry Sibiryakov]

'Alex Peshkoff' via firebird-devel wrote 07.06.2023 19:00:
> What about clean-up of this parameter?

+1.
And leave only "EngineXX" in provider list on server side as well.

--
WBR, SD.

[Alex Peshkoff]

On 6/7/23 22:07, 'Dimitry Sibiryakov' via firebird-devel wrote:
> And leave only "EngineXX" in provider list on server side as well.

Let's not mix everything in single cleanup. Next, suggested change
breaks 'execute statement on external', which is standard, actively used
feature. IMO not good.

[Dimitry Sibiryakov]

'Alex Peshkoff' via firebird-devel wrote 08.06.2023 8:22:
> Next, suggested change breaks 'execute statement on external', which is
> standard, actively used feature. IMO not good.

Not necessarily. Server can use a separate list of engines loading them by
PluginManager instead of Dispatcher.

--
WBR, SD.

[Alex Peshkoff]

Yes, it can - but should better avoid that. As you have correctly
suggested last week it's better to work with the list of providers in
yValve, specially designed level.
To make such changes there should be VERY good reason for it, and I do
not see it here.

BTW, I've found a very simple way to avoid infinite recursion not
touching Redirection at all. Anyway: it should better be cleaned up no
matter of that, but in fb5 we may just deprecate it, leaving full
cleanup for fb6.

[Dimitry Sibiryakov]

'Alex Peshkoff' via firebird-devel wrote 09.06.2023 13:39:
> BTW, I've found a very simple way to avoid infinite recursion not touching
> Redirection at all.

I don't see how exactly your commit prevent recursion but no changes in API
is good, thanks.

--
WBR, SD.

[Alex Peshkoff]

On 6/9/23 14:44, 'Dimitry Sibiryakov' via firebird-devel wrote:
> 'Alex Peshkoff' via firebird-devel wrote 09.06.2023 13:39:
>> BTW, I've found a very simple way to avoid infinite recursion not
>> touching Redirection at all.
>
>   I don't see how exactly your commit prevent recursion

This is main change:

@@ -8092,7 +8087,7 @@ static bool get_new_dpb(ClumpletWriter& dpb, const
ParametersSet& par)
  *
  **************************************/
    bool redirection = Config::getRedirection();
-    if (((!redirection) && dpb.find(par.address_path)) ||
dpb.find(par.map_attach))
+    if (((loopback || !redirection) && dpb.find(par.address_path)) ||
dpb.find(par.map_attach))
    {
        status_exception::raise(Arg::Gds(isc_unavailable));
    }

Loopback provider will never perform redirection, possible only with
expicit node name.