CCBill links with encoded '&' don't work
 

cd34 posted the following in a blogging forum thread, but the ramifications are widespread enough that I felt it needed more exposure.

http://www.greenguysboard.com/board/...19&postcount=5

In lay terms, if your CCBill referral links use & in place of just the & the CCBill cookie identifying the affiliate does not get set.

Some web editors have a habit of encoding ampersands and other special characters as you type them, as that is the correct way to code if you want your pages to validate.

I did a search through the hundreds of galleries I've made over the last couple of years, and I did find several dozen with encoded referral links.

I will also start doing a spot check on sponsor hosted galleries to make sure those links do not contain encoded ampersands.

Hopefully someone from CCBill will see this and bump it up the line to the right people to find a resolution on their end. I would guess that fair number of affiliate sales are going uncredited due to this issue.

Toby
That is interesting and important information.
Thank You :)

That's a problem that's been around for YEARS - I remember MaxCash's sites way back in the day had the "&" problem.

Thanks for that info Toby - I always wondered why my web editor would change & to &amp - would drive me nuts .. I'm pretty sure I changed alot of them to look exactly like the sponsors ref link... but I am sure there are still a lot of them floating around with the &amp in them ... grr just what I needed today.. to look thru my codes. |roses|

I first noticed this about 5 years ago when I got into the biz and was using Dreamweaver as an editor. Damn thing was constantly changing affiliate links |banghead|

That issue was one of the things that got me to start hand coding...no more wysiwyg editors for this porn slinger. And no more issues with affiliate codes getting fucked up either |thumb

Don't code with a WYSIWYG editor...

Code by hand using something like this http://www.textpad.com/

I've coded everything by hand using TextPad since I started in the biz. It's totally awesome.

And it's free. :)

Although it is worth buying a licence. Features include...

• Search & Replace
• Instant upper case / lower case / sentence case convertion
• Good spell checker

There's a lot more in there too, and it won't alter your code like most editors do (including Notepad).

Yup, text editors are your friend |thumb

I've been using NoteTab since dumping DW 5 years ago.

Holy shit! You mean I'm losing money!? I've got a lot of links to fix!!! |shocking|

Thanks for pointing that out Toby. :)

I use DW. I just checked, and I notice it only encodes links I've edited in some way. |huh

I really like using DW though... I'm going to see if I can't turn that auto-encoding &'s off.

I use DW and haven't had that problem (I think LOL) but I use the code view to do everything then preview it in design so I think that's why.

I've been using DW since it was first introduced. The last two versions (MX 2004 and Studio 8) have been far better about when it automatically encodes as you type, usually only doing so if you are typing plain text in design view.

I use Namo & it's friendly to the link codes with "&" in them (for the most part - lol)

Wasn't Front Page the one that always messed the codes up?

that's what I thought. I have MX & was told never to do any coding or moving things around in design view
Front Page is a nightmare |scared| lol

On closer inspection, I figured out that's exactly the case.

Before I upgraded to MX I did a lot of copy/paste. Only a few old things were affected... and mostly because of the silly ways I was doing things back then, so I wouldn't consider the error DW's fault anyway. |loony|

Would like this confirmed...cause maybe i am loosing money

Good post... I remembered I saw it somewhere and found it, see
http://www.dwfaq.com/Tutorials/Misce...s_encoding.asp

At least, I cannot blame myself for doing sites in a plain text editor.

BUT
if you are using scripts, you have to check the url encoding option or they break at the & , it has happened to me with my very first copy of smart thumbs. The links worked from the gallery preview area and I forgot to click all of them when output to the index.shtml.

Yes, I learned that hard way also... I went 0 for 2 months with Lady- Sonia.. until John looked at my traffic... I was using "front page" & arles to make galleries... Live and Learn! After removing the "amp" code things went back to normal! |angry|

Did you read the post I linked to by cd34? How much more confirmation do you need?

Front Page would even double fuck you in that you could change a code and when you looked at it again in the web view it would change the codes back again!

Is this happening with any other sponsors or is it just ccbill?

As far as I know, this is just a CCBill issue.

cd34 saved a lot of money and pain for many of us with this information. Thanks for the heads up Toby! :)

I believe you are spreading bad information here. In your test you sent a get request with the html entity in the request. When a browser sends the request I believe it decodes the link before it sends the get request. I tried it out with firefox and the web developer plugin and the cookie still gets set with the ;amp in the source.

Now for scripts with header redirects, you would want to be careful, but no need to change ;amp to & in your regular html.

In Firefox 1.5.0.6 with cookies set to 'Ask Everytime'

if I key the link in directly into firefox, & will not set the cookie
If I key the link in directly with & rather than &, it will set the cookie
If I cut and paste a link from a page set with a doctype of transitional, it works.
If I cut and paste a link on a doctype set with strict and the url not contained within CDATA (in other words, a page that won't validate) , the cookie is not set.

Additionally, if the link is coded through a script and sent as:

it will not set the cookie because the location header that 99% of the tradescripts are using doesn't de-entify before sending to ccbill.

IE exhibits some odd behavior depending on which version you use. 5.5 does not deentify before sending in my tests. 6.0 does most of the time, but, failed once. I believe ccbill should set the cookie each time regardless of whether there is already a cookie present for that master account number, but, that isn't what I observed in one of the tests I did above. And after it happened, I couldn't duplicate it.

According to the RFC, the browser is supposed to deentify when going to a url, but, clearly when you cut and paste a url into firefox, there is no way for firefox to guess what action it should take.

Personally, I wouldn't want to rely on the browser guessing at what is supposed to happen.

Just to clarify you are talking about browser problems deentifying when copying and pasting entities directly to the address bar and not when links are clicked on a page?

if a surfer right-clicks on a url on a page and pastes it into their browser, depending on a few different factors, they can get the entified or deentified link.

Since there is some inconsistency there, or, when used in trade scripts, etc, it just seems to me that better safe than sorry would be the rule of thumb. Especially since IE 5.5 also seems to exhibit the behavior even on clicked links.

Has anyone talked to a ccbill rep on this?

Everyone is blaming their text editors for encoding ampersands when really that's what they should be doing. I think it's ccbill that needs to address this on their end. Would it be that hard credit links with encoded ampersands?

Going through all our links looking for encoded ampersands seems like a lot of unnecessary work especially considering that that's the way they should be written.

Given time and exposure this may even hurt pay sites as webmasters might choose to not bother with sites that use referral links in this "risky" format.

I am very newbie so please be gently.
Question is
can I change the code (replace & with just &) on existing submitted free sites and then upload it to server? Will I be banned for this?

I have found several affected links to sponsor on my sites.

Thank you
Bertik

I did that in the past with no problems.

I'd like to hear what ccBill has to say about it.|catfight|
I have found a few PPC linksthat ended up with the encoded amp. It seems to be only some links that I have gone back and modified though.|club|

Same here. I guess those nifty html editors don't like creative construction of urls. |loony|

Actually I was referring to their online maintenance systems. Probably in PHP or CGI.

Ya lost me... whose maintenance system? |confused|

A few of the PPC advertising programs have a small problem with encoding the links if you have gone back and change the links.

I never have this problem in normal html since I use a text editor, but i do have it in wordpress posts. Anyone knows a solution to that?

Modify your wordpress now, and every time you update? |huh

I'm not sure I understand what you mean virgohippy