Create Rebateaccess.com.xml

[jeremyn]

No description provided.

[fuglede]

The subdomain www causes issues: connections to https://www.rebateaccess.com are refused.

[jeremyn]

I'm not associated with this site and don't know what should and shouldn't work. It seems to offer $STORE.rebateaccess.com subdomains for various $STOREs such as in the test URLs I included. http://www.rebateaccess.com currently looks like a placeholder.

So I agree with your comment but I'm not sure what you are asking me to do. Could you please clarify?

[fuglede]

I actually just meant that there would have to be added at least one exclusion, since https://www.rebateaccess.com does not work.

The same problem occurs with the subdomains which also allow for the www prefix: http://www.plantronics.rebateaccess.com/ works, but https://www.plantronics.rebateaccess.com/ does not.

Some other working subdomains I came across while looking at it are (www.)americanstandard.rebateaccess.com, (www.)pantone.rebateaccess.com, and (www.)jabrapartner.rebateaccess.com.

[jeremyn]

It seems to me that this domain is simply not configured consistently and is a work-in-progress. (www.)rebateaccess.com says "Coming Soon".

https://www.plantronics.rebateaccess.com and https://www.rebateaccess.com are different problems. The first is "Insecure Connection": "www.plantronics.rebateaccess.com uses an invalid security certificate. The certificate is only valid for the following names: *.rebateaccess.com, rebateaccess.com", while the second is "Unable to connect". Note that even though they have a certificate for "rebateaccess.com", they don't even seem to be listening at https://rebateaccess.com, further supporting the work-in-progress theory.

I think the domains they care about are $STORE.rebateaccess.com. The root rebateaccess.com and all the www sites are probably just configuration issues. I don't think we should add complications to accommodate this. I'm not planning to maintain this ruleset and submit updates for when/if they get https://rebateaccess.com or https://www\* working.

At this point though, please just let me know specifically what changes you want -- or make them yourself, I won't be offended -- and I will probably just do it.

[fuglede]

From the looks of it, I'm also pretty sure that you're right. Now, different people are almost definitely going to have different opinions on this, but given the existence of those misconfigurations, I'll suggest that we go for the safer option of adding explicitly the target hosts that we know work, rather than shooting for the wildcard.

[jeremyn]

Are you asking me to change the XML file to specifically list different subdomains so that instead of having this

    <target host="*.rebateaccess.com" />

it has this?

    <target host="americanstandard.rebateaccess.com" />
    <target host="jabrapartner.rebateaccess.com" />
    etc

[fuglede]

Yep, exactly, unless you have a huge amount (and in that case I could also be convinced that a wildcard is safe).

[jeremyn]

I don't know what should and shouldn't work. I'm not comfortable making a specific list as if I have special knowledge about these domains. If that's what you require to accept the pull request, then I would rather just close it.

[fuglede]

You could always add the ones that you tested. I imagine that people around here typically have limited special knowledge about the domains they add (certainly that's true for myself).

[jeremyn]

I'd still rather not.

[fuglede]

That's fair enough; would you mind if we just build upon your commit?

[jeremyn]

Thanks for asking. At this point I'd rather not be directly involved with this issue in the commit history so I'm going to close this pull request. Please feel free though to use what I wrote as a model for your own changes, if it helps you.

[fuglede]

As far as I see it, any information on securable hosts is helpful, so thanks for that! I've added the hosts to a ruleset in a new PR (which I'll then also try not to link to this thread).