Mailing List Archive

area tag broken for full URLs
If you have a catalog with a VendUrl of www.example.com and you do this:
[area href=http://www.example.net/test form=foo=bar]

...you get this as a result:
http://www.example.com/test?foo=bar

(note how [area] swapped the domain in the URL for the VendUrl domain)

I note that the parsing of the page name in tag_area() parses out the
domain name but puts it in $r instead. $r is not passed onto vendUrl()
at line 2767 of Interpolate.pm, but I believe it was intended to be the
third argument instead of the current undef.

Any comments on why it is undef and if changing this to $r will fix the
issue?


Peter


_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users
Re: area tag broken for full URLs [ In reply to ]
On 05/02/17 23:01, Peter wrote:
> If you have a catalog with a VendUrl of www.example.com and you do this:
> [area href=http://www.example.net/test form=foo=bar]
>
> ...you get this as a result:
> http://www.example.com/test?foo=bar
>
> (note how [area] swapped the domain in the URL for the VendUrl domain)
>
> I note that the parsing of the page name in tag_area() parses out the
> domain name but puts it in $r instead. $r is not passed onto vendUrl()
> at line 2767 of Interpolate.pm, but I believe it was intended to be the
> third argument instead of the current undef.
>
> Any comments on why it is undef and if changing this to $r will fix the
> issue?

And indeed a quick test shows that changing the undef to $r does indeed
fix the issue.


Peter

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users
Re: area tag broken for full URLs [ In reply to ]
On 05/02/17 23:05, Peter wrote:
> On 05/02/17 23:01, Peter wrote:
>> If you have a catalog with a VendUrl of www.example.com and you do this:
>> [area href=http://www.example.net/test form=foo=bar]
>>
>> ...you get this as a result:
>> http://www.example.com/test?foo=bar
>>
>> (note how [area] swapped the domain in the URL for the VendUrl domain)
>>
>> I note that the parsing of the page name in tag_area() parses out the
>> domain name but puts it in $r instead. $r is not passed onto vendUrl()
>> at line 2767 of Interpolate.pm, but I believe it was intended to be the
>> third argument instead of the current undef.
>>
>> Any comments on why it is undef and if changing this to $r will fix the
>> issue?
>
> And indeed a quick test shows that changing the undef to $r does indeed
> fix the issue.

Any comments on this? This seems to be an old bug and I want to try to
make certain that I'm not mucking something important up by fixing it.


Peter

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users
Re: area tag broken for full URLs [ In reply to ]
On 02/09/2017 08:10 AM, Peter wrote:
> On 05/02/17 23:05, Peter wrote:
>> On 05/02/17 23:01, Peter wrote:
>>> If you have a catalog with a VendUrl of www.example.com and you do this:
>>> [area href=http://www.example.net/test form=foo=bar]
>>>
>>> ...you get this as a result:
>>> http://www.example.com/test?foo=bar
>>>
>>> (note how [area] swapped the domain in the URL for the VendUrl domain)
>>>
>>> I note that the parsing of the page name in tag_area() parses out the
>>> domain name but puts it in $r instead. $r is not passed onto vendUrl()
>>> at line 2767 of Interpolate.pm, but I believe it was intended to be the
>>> third argument instead of the current undef.
>>>
>>> Any comments on why it is undef and if changing this to $r will fix the
>>> issue?
>>
>> And indeed a quick test shows that changing the undef to $r does indeed
>> fix the issue.
>
> Any comments on this? This seems to be an old bug and I want to try to
> make certain that I'm not mucking something important up by fixing it.
>
>
> Peter

Hello Peter,

I never thought of using [area] for full URLs ...

Regards
Racke

>
> _______________________________________________
> interchange-users mailing list
> interchange-users@icdevgroup.org
> http://www.icdevgroup.org/mailman/listinfo/interchange-users
>


--
Ecommerce and Linux consulting + Perl and web application programming.
Debian and Sympa administration.

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users
Re: area tag broken for full URLs [ In reply to ]
> -----Original Message-----
> From: interchange-users-bounces@icdevgroup.org [mailto:interchange-users-
> bounces@icdevgroup.org] On Behalf Of Peter
> Sent: Thursday, February 9, 2017 09:10
> To: interchange-users@icdevgroup.org
> Subject: Re: [ic] area tag broken for full URLs
>
> On 05/02/17 23:05, Peter wrote:
> > On 05/02/17 23:01, Peter wrote:
> >> If you have a catalog with a VendUrl of www.example.com and you do
this:
> >> [area href=http://www.example.net/test form=foo=bar]
> >>
> >> ...you get this as a result:
> >> http://www.example.com/test?foo=bar
> >>
> >> (note how [area] swapped the domain in the URL for the VendUrl
> >> domain)
> >>
> >> I note that the parsing of the page name in tag_area() parses out the
> >> domain name but puts it in $r instead. $r is not passed onto
> >> vendUrl() at line 2767 of Interpolate.pm, but I believe it was
> >> intended to be the third argument instead of the current undef.
> >>
> >> Any comments on why it is undef and if changing this to $r will fix
> >> the issue?
> >
> > And indeed a quick test shows that changing the undef to $r does
> > indeed fix the issue.
>
> Any comments on this? This seems to be an old bug and I want to try to
make
> certain that I'm not mucking something important up by fixing it.
>

I think that this is intended behavior. When you look at:
http://interchange.rtfm.info/icdocs/tags/area.html

it appears to me that if you are having an external URL that you shouldn't
use the area tag:
'If you want to encode URI arguments into an external URI then you will have
to do it yourself using something like the following:
<a href="http://www.example.com/foo.html?bar=[filter urlencode]hello
world[/filter]">'

So if you take the approach of: You should only use the area tag for
Interchange URLs then the code works as is.

And if you'd make the fix as you suggested there will be some other issues
that will be confusing:

When you have
$opt->{secure} = 1 ...

sub tag_area does:

$urlroutine = $opt->{secure} ? \&secure_vendUrl : \&vendUrl;

return $urlroutine->($page, $arg, undef, $opt);

So in case of $opt->{secure} = 1 it will do secure_vendUrl.

And this does (in Util.pm):
sub secure_vendUrl {
return vendUrl($_[0], $_[1], $Vend::Cfg->{SecureURL}, $_[3]);
}

The 3rd param then is $Vend::Cfg->{SecureURL} ...

So https://whatever.you.want will become SecureURL.

And it even seems redundant here as in sub vendURL you also have:
if($opt->{secure} or exists $Vend::Cfg->{AlwaysSecure}{$path}) {
$r = $Vend::Cfg->{SecureURL};
}

Anyway I think it's better to not touch. :)

CU,

Gert











_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users
Re: area tag broken for full URLs [ In reply to ]
hehe you are right Racke. I would never have thought of doing that,
because that was never the context.

Whatever will they think of next?

On 2/9/2017 4:19 PM, Stefan Hornburg (Racke) wrote:
> On 02/09/2017 08:10 AM, Peter wrote:
>> On 05/02/17 23:05, Peter wrote:
>>> On 05/02/17 23:01, Peter wrote:
>>>> If you have a catalog with a VendUrl of www.example.com and you do this:
>>>> [area href=http://www.example.net/test form=foo=bar]
>>>>
>>>> ...you get this as a result:
>>>> http://www.example.com/test?foo=bar
>>>>
>>>> (note how [area] swapped the domain in the URL for the VendUrl domain)
>>>>
>>>> I note that the parsing of the page name in tag_area() parses out the
>>>> domain name but puts it in $r instead. $r is not passed onto vendUrl()
>>>> at line 2767 of Interpolate.pm, but I believe it was intended to be the
>>>> third argument instead of the current undef.
>>>>
>>>> Any comments on why it is undef and if changing this to $r will fix the
>>>> issue?
>>> And indeed a quick test shows that changing the undef to $r does indeed
>>> fix the issue.
>> Any comments on this? This seems to be an old bug and I want to try to
>> make certain that I'm not mucking something important up by fixing it.
>>
>>
>> Peter
> Hello Peter,
>
> I never thought of using [area] for full URLs ...
>
> Regards
> Racke
>
>> _______________________________________________
>> interchange-users mailing list
>> interchange-users@icdevgroup.org
>> http://www.icdevgroup.org/mailman/listinfo/interchange-users
>>
>


_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users
Re: area tag broken for full URLs [ In reply to ]
On 09/02/17 21:22, Gert van der Spoel wrote:
> I think that this is intended behavior. When you look at:
> http://interchange.rtfm.info/icdocs/tags/area.html

Right, I think this is the case of a long-standing bug having been
documented.

> So if you take the approach of: You should only use the area tag for
> Interchange URLs then the code works as is.

...which is likely why this hasn't turned up before, because hardly
anyone uses it that way.

If you have a look at the code for tag_area() in Interpolate.pm, look at
lines 2728-2752. That entire block is created to deal with fully
qualified URLS and the vast majority of it is created to deal with those
in combination with the form attribute. It is apparent that it is fully
intended to work this way or that code would not be there at all. Note
that the block strips the domain portion of the URL and places it in $r
(which is initialized on line 2723, purposefully outside of the block so
it can be used later in the function). Also note that in no place is
the content of $r actually used, so a lot of effort has been taken to
store content in $r but then it is simply abandoned. This is suggestive
of a feature that was intended but wasn't created properly.

In addition, if you look at the call to vendUrl() at line 2767, note the
3rd arg is undef there. But look at the actual assignment of args to
vendUrl in Util.pm line 1321, it shows that the third arg gets assigned
to $r there. It's not coincidence that $r is the same variable name as
the $r in tag_area() that is never used, it's clearly supposed to be
assigned there (and in my testing when I do change the undef to $r the
code works as it appears it is intended).

Only Mike knows for sure what he intended when he wrote the code, but I
think the evidence points clearly to that it was intended to work this
way and the fact that it doesn't is a bug that is easily fixed.

> And if you'd make the fix as you suggested there will be some other issues
> that will be confusing:
>
> When you have
> $opt->{secure} = 1 ...

This is dealt with in line 2750, when a full URL is passed
$opt->{secure} is overridden to 0, but if the full URL is an https URL
it will still be secure because the https will be passed as part of $r.

> Anyway I think it's better to not touch. :)

I'm gonna disagree here. I've done my homework (as you can see above)
and changing that third arg to $r will not affect any usage where the
href is not a full URL since $r will be undef in that case anyways and
hence be the same as explicitly passing undef as is done now.

The only reason I'm asking is because the current behavior is if you
pass a full URL with a form attribute, then the protocol://domain
portion will be stripped out and replaced by VendUrl. I highly doubt
anyone is relying on this behaviour, but if you are then speak up now
because you're relying on a bug and it should be changed.


Peter

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users
Re: area tag broken for full URLs [ In reply to ]
> On 2/9/2017 4:19 PM, Stefan Hornburg (Racke) wrote:
>> I never thought of using [area] for full URLs ...

On 09/02/17 21:25, Frank Reitzenstein wrote:
> hehe you are right Racke. I would never have thought of doing that,
> because that was never the context.
>
> Whatever will they think of next?

The idea is you can use it to compile form attributes to any URL, not
just Interchange pages, plus you can use it as a generic URL parser
where you can pass either an IC page name or a full URL easily. This
might come in handy if you have say a banners table with an href column
for the href to link the banner to. By passing the href column directly
to the area tag you can turn it into the full URL and it would allow you
to put either a bare page name or a full URL into the column if you want
without requiring additional parsing or a separatte field to indicate if
it's a page name or a full URL for the link.

I'm sure there are other handy uses of it as well.


Peter

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users
Re: area tag broken for full URLs [ In reply to ]
> -----Original Message-----
> From: interchange-users-bounces@icdevgroup.org [mailto:interchange-users-
> bounces@icdevgroup.org] On Behalf Of Peter
> Sent: Thursday, February 9, 2017 22:46
> To: interchange-users@icdevgroup.org
> Subject: Re: [ic] area tag broken for full URLs
>
> On 09/02/17 21:22, Gert van der Spoel wrote:
> > I think that this is intended behavior. When you look at:
> > http://interchange.rtfm.info/icdocs/tags/area.html
>
> Right, I think this is the case of a long-standing bug having been
documented.
>
> > So if you take the approach of: You should only use the area tag for
> > Interchange URLs then the code works as is.
>
> ...which is likely why this hasn't turned up before, because hardly anyone
uses
> it that way.
>
> If you have a look at the code for tag_area() in Interpolate.pm, look at
lines
> 2728-2752. That entire block is created to deal with fully qualified URLS
and
> the vast majority of it is created to deal with those in combination with
the
> form attribute. It is apparent that it is fully intended to work this way
or that
> code would not be there at all. Note that the block strips the domain
portion
> of the URL and places it in $r (which is initialized on line 2723,
purposefully
> outside of the block so it can be used later in the function). Also note
that in
> no place is the content of $r actually used, so a lot of effort has been
taken to
> store content in $r but then it is simply abandoned. This is suggestive
of a
> feature that was intended but wasn't created properly.
>
> In addition, if you look at the call to vendUrl() at line 2767, note the
3rd arg is
> undef there. But look at the actual assignment of args to vendUrl in
Util.pm
> line 1321, it shows that the third arg gets assigned to $r there. It's
not
> coincidence that $r is the same variable name as the $r in tag_area() that
is
> never used, it's clearly supposed to be assigned there (and in my testing
when I
> do change the undef to $r the code works as it appears it is intended).
>
> Only Mike knows for sure what he intended when he wrote the code, but I
> think the evidence points clearly to that it was intended to work this way
and
> the fact that it doesn't is a bug that is easily fixed.
>
> > And if you'd make the fix as you suggested there will be some other
> > issues that will be confusing:
> >
> > When you have
> > $opt->{secure} = 1 ...
>
> This is dealt with in line 2750, when a full URL is passed $opt->{secure}
is
> overridden to 0, but if the full URL is an https URL it will still be
secure because
> the https will be passed as part of $r.

Good point I overlooked that one. :)

>
> > Anyway I think it's better to not touch. :)
>
> I'm gonna disagree here. I've done my homework (as you can see above) and
> changing that third arg to $r will not affect any usage where the href is
not a
> full URL since $r will be undef in that case anyways and hence be the same
as
> explicitly passing undef as is done now.
>
> The only reason I'm asking is because the current behavior is if you pass
a full
> URL with a form attribute, then the protocol://domain portion will be
stripped
> out and replaced by VendUrl. I highly doubt anyone is relying on this
> behaviour, but if you are then speak up now because you're relying on a
bug
> and it should be changed.
>
>


_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users
Re: area tag broken for full URLs [ In reply to ]
On Fri, 10 Feb 2017, Peter wrote:

> I'm gonna disagree here. I've done my homework (as you can see above)
> and changing that third arg to $r will not affect any usage where the
> href is not a full URL since $r will be undef in that case anyways and
> hence be the same as explicitly passing undef as is done now.
>
> The only reason I'm asking is because the current behavior is if you
> pass a full URL with a form attribute, then the protocol://domain
> portion will be stripped out and replaced by VendUrl. I highly doubt
> anyone is relying on this behaviour, but if you are then speak up now
> because you're relying on a bug and it should be changed.

I don't recall ever seeing anyone use [area] with a full URL, and your
analysis sounds reasonable. +1 from me for fixing the bug as you
described.

Jon


--
Jon Jensen
End Point Corporation
https://www.endpoint.com/

_______________________________________________
interchange-users mailing list
interchange-users@icdevgroup.org
http://www.icdevgroup.org/mailman/listinfo/interchange-users