I'm just curious is it possible (or advisable) to use _linkbypost() instead of just _link() on cross domain links with Google Analytics to avoid the problems I'm having with the long query strings that _link() produces.
_link() uses _GET to pass data by attaching a huge gibberish query string to the destination url which causes me a few headaches: It prevents my caching scheme (which keys off exact matching urls), drives many of my social media widgets crazy (which have proven super important to my business), and just looks scary and ugly which I've found really does affect how much many users trust your site.
So I'm hoping I can get the same ability to track without losing my clean orderly cacheable urls by passing that data via post instead of get. But since I don't really understand how post works I don't know if this if feasible, or if it is just a really bad idea for some other reason.
I know _linkbypost() needs a form object to function, so my plan was to add an onSubmit function to each cross-domain link like so:
var crossLink = $(this).attr("href");
var formHTML = '<form id="crossForm" action="'+crossLink+'" method="post"></form>';
$('body').append(formHTML);
var crossForm = $('#crossForm');
_gaq.push(['_linkByPost', crossForm]);
return false;
Assuming it's not a bad idea to begin with, does that implementation seem reasonable?
I'm pretty sure _linkByPost will still sen the data through your url. So I don't think that's a solution to your problem.
You can use _link to pass the query parameters at the anchor (instead as query parameters) part of the url using it's second argument as true.
_gaq.push(['_link', 'http://www.myothersite.com', true]);
This will generate a url like
http://www.myothersite.com#__utma=1.2.123123...
You will also need _gaq.push(['_setAllowAnchor', true]); to tell GA to read the data from the Anchor.
It should be enough to not break your cache anymore and reduce the issue with your social plugins.
Related
As a end-point user of an API, how can I list all parameters available to pass the query? In my case (stats about Age of Empires 2 matches), the website describing the API has a list with some of them but it seems there are more available.
To provide more context, I'm extracting the following information:
GET("https://aoe2.net/api/matches?game=aoe2de&count=1000&since=1632744000&map_type=12")
but for some reason the last condition, map_type=12 does nothing (output is the same as without it). I'm after the list of parameters available, so I can extract what I want.
PD: this post is closely related but does not focus on API. Perhaps this makes a difference, as the second answer there seems to suggest.
It is not possible to find out all available (undocumented) query parameters for a query, unless the API explicitly provides such a method or you can find out how the API server processes the query.
For instance, if the API server code is open source, you could find out from the code how the query is processed. Provided that you find the code also.
The answers in the post you linked are similarly valid for an API site as well as for one that provides content for a web browser (a web server can be both).
Under the hood, there is not necessarily any difference between an API server or a server that provides web content (html) in terms of how queries are handled.
As for the parameters seemingly without an effect, it seems that the API in question does not validate the query parameters, i.e., you can put arbitrary parameters in the query and the server will simply ignore parameters that it is not specifically programmed to use.
The documentation on their website is all any of us have to go by https://aoe2.net/#api
You can't just add your own parameters to the URL and expect it to return a value back as they have to have coded it to work that way.
Your best bet is to just extract as much data as you can by increasing the count parameter, then loop through the JSON response and extract the map_type from there.
JavaScript example:
<script>
json=[{"match_id":"1953364","lobby_id":null,"game_type":0},
{"match_id":"1961217","lobby_id":null,"game_type":0},
{"match_id":"1962068","lobby_id":null,"game_type":1},
{"match_id":"1962821","lobby_id":null,"game_type":0},
{"match_id":"1963814","lobby_id":null,"game_type":0},
{"match_id":"1963807","lobby_id":null,"game_type":0},
{"match_id":"1963908","lobby_id":null,"game_type":0},
{"match_id":"1963716","lobby_id":null,"game_type":0},
{"match_id":"1964491","lobby_id":null,"game_type":0},
{"match_id":"1964535","lobby_id":null,"game_type":12},];
for(var i = 0; i < json.length; i++) {
var obj = json[i];
if(obj.game_type==12){
//do something with game_type 12 json object
console.log(obj);
}
}
</script>
Making an ad manager plugin for WordPress, so the advertisement code can be almost anything, from good code to dirty, even evil.
I'm using simple sanitization like:
$get_content = '<script>/*code to destroy the site*/</script>';
//insert into db
$sanitized_code = addslashes( $get_content );
When viewing:
$fetched_data = /*slashed code*/;
//show as it's inserted
echo stripslashes( $fetched_data );
I'm avoiding base64_encode() and base64_decode() as I learned their performance is a bit slow.
Is that enough?
if not, what else I should ensure to protect the site and/or db from evil attack using bad ad code?
I'd love to get your explanation why you are suggestion something - it'll help deciding me the right thing in future too. Any help would be greatly appreciated.
addslashes then removeslashes is a round trip. You are echoing the original string exactly as it was submitted to you, so you are not protected at all from anything. '<script>/*code to destroy the site*/</script>' will be output exactly as-is to your web page, allowing your advertisers to do whatever they like in your web page's security context.
Normally when including submitted content in a web page, you should be using htmlspecialchars so that everything comes out as plain text and < just means a less then sign.
If you want an advertiser to be able to include markup, but not dangerous constructs like <script> then you need to parse the HTML, only allowing tags and attributes you know to be safe. This is complicated and difficult. Use an existing library such as HTMLPurifier to do it.
If you want an advertiser to be able to include markup with scripts, then you should put them in an iframe served from a different domain name, so they can't touch what's in your own page. Ads are usually done this way.
I don't know what you're hoping to do with addslashes. It is not the correct form of escaping for any particular injection context and it doesn't even remove difficult characters. There is almost never any reason to use it.
If you are using it on string content to build a SQL query containing that content then STOP, this isn't the proper way to do that and you will also be mangling your strings. Use parameterised queries to put data in the database. (And if you really can't, the correct string literal escape function would be mysql_real_escape_string or other similarly-named functions for different databases.)
I want to be able to set the UTM variables manually
So instead of having a webpage
http://mysite.net/index.html?utm_source=source&utm_medium=inbound&utm_campaign=campname
I want to be able to set these with javascript. Looking through the documentation I couldn't find any set methods for these, only the set key methods.
https://developers.google.com/analytics/devguides/collection/gajs/gaTrackingCampaigns
I have also tried
_gaq.push(['_trackPageview', '/index.html?utm_source=source&utm_medium=inbound&utm_campaign=campname']);
Although as far as I can tell this doesn't work. The only way I can now see of getting this to work will be to set these using a hash value:
ie:
http://mysite.net/index.html#utm_source=In+House&utm_medium=email&utm_campaign=Fall+email+offers
_gaq.push(['_setAllowAnchor', true]);
Is there a better way?
edit
Actually it seems there IS a way to do this using GA code!
previous answer
I've needed to do this in the past as well and I could not find any way to do it on-page. I believe the only way you can really do this is by reading GA's __utmz cookie and rewriting the cookie with the value(s) you want.
example:
This is what __utmz would normally look like on if you go to www.mysite.com with no url params (the numbers in the cookie will be different):
URL: http://www.mysite.com
__utmz cookie value: 97566023.1329384140.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
Here is what it would look like if you were to go to the URL with the values in the URL (the official way to do it):
URL: http://mysite.net/index.html?utm_source=In+House&utm_medium=email&utm_campaign=Fall+email+offers
__utmz cookie value: 97566023.1329384140.1.1.utmcsr=In House|utmccn=Fall email offers|utmcmd=email
And the cookie will have these values on subsequent page views, and you will see them sent to GA in the utmcc URL param in the request URL. So basically you can alter the __utmz cookie to the values you want. Would probably be more convenient to write a wrapper function to easily set it. Honestly, I don't know why GA doesn't provide a way to do this with a baked in wrapper function...
Warning: Non-static method Zend_Controller_Request_Http::getCookie() should not be called statically in..
Iam trying the following to get Cookie values:
$cookieData = Zend_Controller_Request_Http::getCookie($key, $default);
is there an better way to this?
getCookie() method is not static, it should be called on an object.
I believe this code is from your controller, so it should basically look like
$request = $this->getRequest();
$cookieData = $request->getCookie('someCookie', 'default');
This is a slight side note, yet it may just well help avoid long fruitless hours. From my experience, the problems that occur when one cannot retrieve value from $_COOKIE in zf1 and other frameworks occur mostly because setCookie is so easy to use one forgets to add the path and the domain like so:
setcookie('cookieName', 'cookieValue', $finalExpirationTime,'/','.yourdomain.com');
and instead do this:
setcookie('cookieName', 'cookieValue', $finalExpirationTime);
This gets real annoying especially so when working on Windows with ip's instead of actual domains. Another thing to look out for would be the dot (.) in front of the domain. As stated in the manual: Older browsers still implementing the deprecated ยป RFC 2109 may require a leading . to match all subdomains.
Hope this helps
Should we guard against unanticipated user input from dropdown lists? Is it plausible to expect a user to somehow modify a dropdown list to contain values that weren't originally included?
How can they do this and how can we stop it?
Absolutely check for that.
Do something like this pseudo code on the receiving end:
if { posted_value is_element_of($array_of_your_choices) }
//processing code
else {
//prompt them for good input
}
So for example: Your dropdown list is of Primary Colors they'd like their house painted. You'd have (in PHP)
$colors = array('red', 'blue', 'yellow');
if in_array($_POST['color'], $colors)
{ //process this code! dispatch the painters; }
else {echo "sorry, that's not a real color";}
Edit: This is certainly possible. If your values are being submitted via a GET request, then the user can simply enter www.example.com/?price=0 to get a free house. If it's a POST request, it may seem a little more difficult, but it's really not:
curl_setopt($ch, CURLOPT_POSTFIELDS,"price=0");
People could just use cURL to directly manipulate a POST request, in addition to a trivially large number of other clients.
A user can simply hand-write a HTTP request which has has filled in malicious data. For GET requests, for example, you may have a "State" dropdown that lists Alabama, Arkansas, etc. He may put http://example.com?state=evilstuff just simply into the browser url bar.
This is easily prevented since you already know exactly what is in the dropdown list. Simply checking to see if the input is in that list or not should be sufficient to prevent against injection-like attacks. If he puts in something other than a valid state name, throw an error.
This can only be done by modifying the HTTP response. So,
yes, it can be done and you need to safeguard against it (i.e. check if this can be a security threat and, if yes, validate the input), but
no, you don't need to bring a "nice" error message, since this cannot happen to a normal user "by accident".
When I'm bored, I edit drop-down lists in web sites just for fun. Mostly it just breaks the site, but at least once I could have gotten free or drastically reduced prices on tickets just by playing with the site's hidden fields. (Alas it was for a company I worked for, so I had to instead report the bug.)
Yes, a malicious user can submit data to your server without ever using your form, and could submit data that's not normally included in your dropdown list. This is a trivial form of attack that's often exploited in the real world.
Always check for valid input!
Some of the other answers are absolutely correct, you MUST validate on the server-side ANY data coming from the user side.
At work, we use tools such as the Firefix plug-in Tamper Data to manipulate and view data thats being posted to the server, after any client-side (javascript) validation has been done. Also, you can even use simple tools such as Firebug to visibly alter drop-down boxes to contain values that weren't put there by the server before submitting it.