The formatted parameters to the AuthMySQLUserCondition and AuthMySQLGroupCondition in this version are not correct.
I introduced these parameters WITH a trailing space to avoid recursive formatting. In this version, the trailing space is removed, causing a recursion. If it finds a part of a string which looks like a requested format, it tries to format it again. Putting back the trailing spaces in the formats fixes this.
No, the lack of a trailing space is intentional and correct.
For instance - let's say the user wanted an IP address to match a column. He could have something like:
ip='%a'
which might expand to
ip='123.123.123.123'
If there were a trailing blank after the formatting character, there would be an extra blank before the trailing quote mark - and the match would fail.
We looked at the possibility of a recursion - but are there any parameters which could cause this? For instance - an ip address would never have a % in it.
And if there is a parameter which could cause recursion, how would the trailing blank help? Would it be impossible to have the trailing blank in the expanded parameter?
I will add that we're looking more into this area with the possibility of processing cookies, also. So we'll be making some changes in this area, but haven't decided exactly what yet.
Jerry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The trailing space was intentional and only used as part of the format to avoid recursion.
example:
vhost='%%v %'
if $v equals for example a-domain.com it would expand to
vhost='%a-domain.com%'
if you do this with the current version without the trailing space:
vhost='123.123.123.123-domain.com%'
So, the trailing space is not part of the equision, but part of the format. I fixed it on my working version, and ALL authentications work perfectly now.
Guido
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand you intentionally put a space in there. However, I intentionally removed it because it is counter-intuitive. Other functions such as printf() do not strip trailing spaces, for instance. We need to emulate existing functions as much as possible.
I see now how your example can cause recursion. However, it's not as appropriate.
We're going to change the way the string is parsed in the next release (working on it now). There will not be a possiblity of recursion in what he have in mind, due to the way the string will be processed.
One additional item will be the use of the % in the string. If you want a % in the string, you will have to use two of them ("%%"). This emulates printf and other functions. So, in your example, you would use
vhost='%%%v%%'
to give the output
vhost='%123.123.123.123-domain.com%'
As I said - it's in the works, with some other things. We hope to have it in available for testing in the next few days.
Jerry
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The formatted parameters to the AuthMySQLUserCondition and AuthMySQLGroupCondition in this version are not correct.
I introduced these parameters WITH a trailing space to avoid recursive formatting. In this version, the trailing space is removed, causing a recursion. If it finds a part of a string which looks like a requested format, it tries to format it again. Putting back the trailing spaces in the formats fixes this.
This is how it should look:
format formats[] = {{"%h ", format_remote_host},
{"%a ", format_remote_ip},
{"%f ", format_filename},
{"%V ", format_server_name},
{"%v ", format_server_hostname},
{"%H ", format_protocol},
{"%m ", format_method},
{"%q ", format_args},
{"%r ", format_request},
{"%U ", format_uri}};
The formats in the CONFIGURE document should therefore also be corrected.
Hello, Guido,
No, the lack of a trailing space is intentional and correct.
For instance - let's say the user wanted an IP address to match a column. He could have something like:
ip='%a'
which might expand to
ip='123.123.123.123'
If there were a trailing blank after the formatting character, there would be an extra blank before the trailing quote mark - and the match would fail.
We looked at the possibility of a recursion - but are there any parameters which could cause this? For instance - an ip address would never have a % in it.
And if there is a parameter which could cause recursion, how would the trailing blank help? Would it be impossible to have the trailing blank in the expanded parameter?
I will add that we're looking more into this area with the possibility of processing cookies, also. So we'll be making some changes in this area, but haven't decided exactly what yet.
Jerry
Jerry,
The trailing space was intentional and only used as part of the format to avoid recursion.
example:
vhost='%%v %'
if $v equals for example a-domain.com it would expand to
vhost='%a-domain.com%'
if you do this with the current version without the trailing space:
vhost='123.123.123.123-domain.com%'
So, the trailing space is not part of the equision, but part of the format. I fixed it on my working version, and ALL authentications work perfectly now.
Guido
Guido,
I understand you intentionally put a space in there. However, I intentionally removed it because it is counter-intuitive. Other functions such as printf() do not strip trailing spaces, for instance. We need to emulate existing functions as much as possible.
I see now how your example can cause recursion. However, it's not as appropriate.
We're going to change the way the string is parsed in the next release (working on it now). There will not be a possiblity of recursion in what he have in mind, due to the way the string will be processed.
One additional item will be the use of the % in the string. If you want a % in the string, you will have to use two of them ("%%"). This emulates printf and other functions. So, in your example, you would use
vhost='%%%v%%'
to give the output
vhost='%123.123.123.123-domain.com%'
As I said - it's in the works, with some other things. We hope to have it in available for testing in the next few days.
Jerry