Recognizing target page

[Dinghus]

I rec'd one side of some code so I can't see how this is done. It is an affiliate link that uses target="aff_ID" in the link.

My question is how does the other end tell what is in the target parameter?

It isn't in the cgi variables.

[Dan_Bracuk]

Your question is not clear. Specifically, I don't know what you mean by:
affiliate link
other end
or target parameter.

[Mr_Black]

If you are talking about <a .... target="aff_ID" ...>, there is no way to know this on the server side, unless you also explicitly pass it, as URL parameter, form field, header, etc.

[Dinghus]

Hmmm Dan, you don't do any affiliate work I take it. An affiliate is a person who is selling another person's product. They have a link that people click on that passes information about who the affiliate is so they get paid accordingly. So the normal way is with something like
< a href=" http://www.somesite.com/index.htm?affiliate_id=123" >

The "other end" is the site that is receiving this information and a target parameter is like target="_blank" _blank is the parameter.

Now I did some investigating and it appears that people tend not to click on links they know are affiliate links. For some reason people think it is bad for somebody to get paid for selling other peoples' products. Go figga.

So in an attempt to hide the fact that it is an affiliate link somebody has figured out a way to read the target parameter. With all due respect, Mr Black, it is definitly possible since it seems a number of people are now doing it.

I found some affiliate links that are <a href=" http://www.somesite.com" target="affiliate_id">

Unfortunately when I ask the people that are using them they are clueless. They had somebody do it for them and those people aren't talking.

Now I'm going to lie awake at nights trying to figure this one out.

[Newsgroup_User]

view the source on a page you know uses this target technique and see if
it also uses some javascript to re-write the link and include the
affiliate id in the query string after the link has been clicked on.
with modern js libraries like jquery etc it is trivial, and the actual
link's href on the page stays the same - it is only altered via injected
onclick event.

Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com/

[Dan_Bracuk]

quote:

---

Originally posted by: Dinghus
I rec'd one side of some code so I can't see how this is done. It is an affiliate link that uses target="aff_ID" in the link.

My question is how does the other end tell what is in the target parameter?

It isn't in the cgi variables.

---

I have an existing page with a target="_blank" attribute in the anchor tag. When I run it, the page in the new browser has the correct value in the cgi.http_referrer variable.

What's the part you're having trouble with?

[Newsgroup_User]

hmm... interesting...
just ran a short test and it appears that the target attribute does not
just disappear into the void, but is somehow passed to the requested
page... must be in the headers...

tested in ff2:

<a href="page1.cfm" target="myaffiliateid">page 1</a>
<a href="page2.cfm" target="myaffiliateid">page 2</a>



Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com/

[Dinghus]

Okay, no javascript. Something on the serverside of the URL is reading the target attribute.

Dan, how can I tell that the target = blank? Or anything else for that matter? When it gets to the URL being called? I don't care that it correctly opens the page in a new browser window, I want to know what is in the target="????". How do I read that at the new URL?

I admit I think it is impossible, but if it is impossible, then why are these companies using it? A scam?

[Newsgroup_User]

nope, nothing in the headers...
it must be controlled by browser...

bottom line: there appears to be no way to get the value of target
attribute of the calling link on the requested page.

if no js is involved, then Dan must be correct and the cgi.http_referer
is looked at to identify the calling website.

Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com/

[Dinghus]

AH HAAAA!
Okay, here is the scoop. If you do a link like that, the TARGET attribute becomes the NAME of the new window. So to find out what the target attribute is, use a little script in the new window and do self.name There is the target attribute.

Pretty clever. I like it. I may use it for some of my stuff. :)

[Newsgroup_User]

interesting...

Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com/

[Dinghus]

This would be a good way to pass info that you don't really want in the URL. Of course anybody doing a view source will see it anyway just like using form fields to send the info.

[Newsgroup_User]

> AH HAAAA!
> Okay, here is the scoop. If you do a link like that, the TARGET attribute
> becomes the NAME of the new window. So to find out what the target attribute
> is, use a little script and do self.name There is the target attribute.
>
> Pretty clever. I like it. I may use it for some of my stuff. :)

You've possibly got this around the wrong way, if I've waded through your
question properly (that itself I'm not sure about).

The TARGET attribute is a client agent instruction, which could cause the
client agent - if the client agent is a web browser which supports such
activity - to put the response in a "window" with the same name as the
value of the target attribute. Or a frame with the same name as the value
of the target attribute. Or launch a new window, giving that window the
name of the value of the target attribute if no already-existing window of
that name exists. Or it could ignore it completely (which is what the next
generation of browsers are likely to do, as the target attribute is
deprecated, for dogmatic and slightly naive - IMO - reasons known best to
the W3C). As with all HTML, it's completely at the discretion of the
browser vendor as to how a target on an anchor tag is handled. However all
the window-based (as distinct from Windows-based) ones seem to follow the
"look for a frame, then look for a window, then create a new window"
approach.

The server side code never knows about any of this because how the client
agent choses to arrange the responses returned from the server are
irrelevant to the server, as it has no bearing on how the server processes
the request.

Coincidentally client-side scripting might also put the value of the target
attribute into a form field or a query-string parameter, or a cookie, so
that that value is accessible to the server when the next request is made
to it, but this is nothing to do with the target attribute, per se.

--
Adam

[Mr_Black]

>So in an attempt to hide the fact that it is an affiliate link somebody has figured out a way to read
> the target parameter. With all due respect, Mr Black, it is definitly possible since it seems a number
> of people are now doing it.

All your activities on the client side, ultimately will have to end with the explicit parameter passing to the server, if of course, you want to inform server about this.

If the task is just to hide "affiliateID=12345", attach a form submittion to "onClick" event and pass this, as a hidden field. This, in fact, will be much cleaner than the trick with frames and windows, although still not 100% reliable.

[Dinghus]

Here is the way this works.
There is a link with a target of say "abcdef" The person clicks on the link and a new window opens. The name of the window is "abcdef". So on the new page must have some javascript that reads the name of the window and puts the value in a hidden form field.

The reason for all this is that the link is NOT a form. And as I said earlier, for some psychological reason, people tend to NOT click on a link when they see it comes up with some sort of affiliate link.

When you do affiliate work you want a person just to have to copy a short line of code, such as a link with or without an image. The other way is to do javascript links.