Develop Reference

Remove personal information from mixpanel javascript tracking call

I'm currently integrating with MixPanel's javascript library and have run into an issue that MixPanel does not seem to have thought about. Our company deals with personally identifiable information(PII), and therefore some data that we pass as params are not appropriate for storage on a third-party service. But MixPanel's default behavior is to include the full url for the current page and the referrer with every tracking event. This makes sense to a degree, but we need to scrub some query parameters out of these fields.
It seems like MixPanel's documentation does not discuss an API for accomplishing this, so any advice from someone more experienced with MixPanel integration would be helpful.

"Our company deals with personally identifiable information(PII), and
therefore some data that we pass as params are not appropriate for
storage on a third-party service."
You should not be passing sensitive data as URL parameters. This is a security no-no: the values end up in browser history (and thus can be retrieved by somebody looking through the browser history) and in server-side logs. Always pass sensitive data through the HTTP body or headers instead.
References:
https://blog.httpwatch.com/2009/02/20/how-secure-are-query-strings-over-https/
Is an HTTPS query string secure?
https://blog.gaborszathmari.me/2015/05/05/session-ids-as-query-parameters-must-die/
http://owasp-aasvs.readthedocs.org/en/latest/requirement-9.3.html

You can actually override the Current URL by setting $current_url in your event, e.g.
mixpanel.track('My Event', {
'$current_url': 'http://www.example.com'
});

Node/Express - How to implement DELETE and PUT requests

I know that I can route to router.get('/object/:id', ...), router.post('/object/new', ...), router.delete('/object/:id', ...), and router.put('/object/:id', ...) and that when I browse to a specific object, the browser will issue a http get request. And I understand that I can post info through a form. But how can I implement the DELETE and PUT methods so that I can edit and delete objects? How do I specify the method used in the route? Do I have to change the route so that it is unique (ie, router.get('/object/delete/:id', ...) and router.get('/object/edit/:id', ...)) and just use get methods?

In your HTML form element you can use the method attribute to specify the method. <form method="put">. However, more typically these type of RESTful API endpoints are called from browsers with javascript as AJAX requests, which can use all of the available HTTP methods. This can be done with the XmlHttpRequest standard API, jQuery's $.ajax, or the front end framework of your choosing.
Do I have to change the route so that it is unique
No, you can have the same URL path with different HTTP methods and those can be handled by different callback functions to behave differently. Conventional REST URL schemes make heavy semantic use of the various HTTP methods requesting the same URL path (GET means get, PUT means replace, etc).

How to get data from remote website?

Lets say there is a url out there e.g. www.website.com/data.jsp
the link has the following JSON data
{"successful":"true","rows":[{"zip":"65472","user_id":"10843","name":"Rufio"}]}
I just want to be able to extract this data at runtime however I am having a hard time getting it using getJSON
$.getJSON("test2.jsp",function(result){
$("div").append(result.rows[0].user_id + " ");
});
Now if I run it using a local file with the data residing in test2.jsp as shown above it appends the user_id. However when I try to access "www.website.com/data.jsp" instead nothing happens. I don't believe the website is configured to work with JSONP either.
I need a way to figure out how to pull this data from the website at run time. Does anyone have any solutions or workarounds?
p.s. Is this something that might need to be sorted out on the other end? The people who own the website set this scenario up to be like a fake api call like typically you would pass in parameters to get back the specific information that you would need. In the case of this endpoint or url it just returns a single record or the file just contains the data listed above. They would like me to extract the data from their url at runtime.

You can't make a normal ajax call to to this other domain due to same origin policy.
You can use JSONP to load the remote page, but looking at that example output you wouldn't be able to access the data unless the remote site is setup for JSONP (assigning the JSON to a variable, calling a callback function, etc).
You could create a server-side passthrough script of your own. You don't mention what server-side technology you have available, but if you can use PHP, you do a passthrough like this:
<?php
echo file_get_contents("http://www.website.com/data.jsp");
?>
PHP (or any other server-side language) can fetch the remote data, and now you can use ajax to call your own script (which works since you're on the same domain).

How does the diigolet bookmarklet get around cross-scripting?

http://www.diigo.com/tools/diigolet
Diigolet essentially allows you to use a bookmarklet to bookmark sites. With the bookmarklet I'm making, I also need to pass the current URL of the site the user is on to my server. Everytime I try this, I get a cross-scripting error.
Does anybody know how to bypass this like the diigolet?

Essentially, they work around the same-origin policy by injecting a script tag with the different-domain URL rather than using an XMLHttpRequest. Note that this is different from a normal JSON request in that the JSON is wrapped in a callback function, for example:
myCallbackFunction(<JSON here>);
(This works because JSON is a subset of JavaScript's object literal notation.)
In their case, they hardcode the name of the callback function as diigolet.callback, but there exists a specification called JSONP that JavaScript libraries such as jQuery support.
Under the JSONP specification, the name of the callback function is passed to the server via a callback=myCallbackFunction parameter in the GET request. Your server-side code needs to handle this appropriately to be able to handle JSONP requests from jQuery.

How to prevent direct access to my JSON service?

I have a JSON web service to return home markers to be displayed on my Google Map.
Essentially, http://example.com calls the web service to find out the location of all map markers to display like so:
http://example.com/json/?zipcode=12345
And it returns a JSON string such as:
{"address": "321 Main St, Mountain View, CA, USA", ...}
So on my index.html page, I take that JSON string and place the map markers.
However, what I don't want to have happen is people calling out to my JSON web service directly.
I only want http://example.com/index.html to be able to call my http://example.com/json/ web service ... and not some random dude calling the /json/ directly.
Quesiton: how do I prevent direct calling/access to my http://example.com/json/ web service?
UPDATE:
To give more clarity, http://example.com/index.html call http://example.com/json/?zipcode=12345 ... and the JSON service
- returns semi-sensitive data,
- returns a JSON array,
- responds to GET requests,
- the browser making the request has JavaScript enabled
Again, what I don't want to have happen is people simply look at my index.html source code and then call the JSON service directly.

There are a few good ways to authenticate clients.
By IP address. In Apache, use the Allow / Deny directives.
By HTTP auth: basic or digest. This is nice and standardized, and uses usernames/passwords to authenticate.
By cookie. You'll have to come up with the cookie.
By a custom HTTP header that you invent.
Edit:
I didn't catch at first that your web service is being called by client-side code. It is literally NOT POSSIBLE to prevent people from calling your web service directly, if you let client-side Javascript do it. Someone could just read the source code.

Some more specific answers here, but I'd like to make the following general point:
Anything done over AJAX is being loaded by the user's browser. You could make a hacker's life hard if you wanted to, but, ultimately, there is no way of stopping me from getting data that you already freely make available to me. Any service that is publicly available is publicly available, plain and simple.

If you are using Apache you can set allow/deny on locations.
http://www.apachesecurity.net/
or here is a link to the apache docs on the Deny directive
http://httpd.apache.org/docs/2.0/mod/mod_access.html#deny
EDITS (responding to the new info).
The Deny directive also works with environment variables. You can restrict access based on browser string (not really secure, but discourages casual browsing) which would still allow XHR calls.
I would suggest the best way to accomplish this is to have a token of some kind that validates the request is a 'good' request. You can do that with a cookie, a session store of some kind, or a parameter (or some combination).
What I would suggest for something like this is to generate a unique url for the service that expires after a short period of time. You could do something like this pretty easily with Memcache. This strategy could also be used to obfuscate the service url (which would not provide any actual security, but would raise the bar for someone wanting to make direct calls).
Lastly, you could also use public key crypto to do this, but that would be very heavy. You would need to generate a new pub/priv key pair for each request and return the pubkey to the js client (here is a link to an implementation in javascript) http://www.cs.pitt.edu/~kirk/cs1501/notes/rsademo/

You can add a random number as a flag to determine whether the request are coming from the page just sent:
1) When generates index.html, add a random number to the JSON request URL:
Old: http://example.com/json/?zipcode=12345
New: http://example.com/json/?zipcode=12345&f=234234234234234234
Add this number to the Session Context as well.
2) The client browser renders the index.html and request JSON data by the new URL.
3) Your server gets the json request and checks the flag number with Session Context. If matched, response data. Otherwise, return an error message.
4) Clear Session Context by the end of response, or timeout triggered.

Accept only POST requests to the JSON-yielding URL. That won't prevent determined people from getting to it, but it will prevent casual browsing.

I know this is old but for anyone getting here later this is the easiest way to do this. You need to protect the AJAX subpage with a password that you can set on the container page before calling the include.
The easiest way to do this is to require HTTPS on the AJAX call and pass a POST variable. HTTPS + POST ensures the password is always encrypted.
So on the AJAX/sub-page do something like
if ($_POST["access"] == "makeupapassword")
{
...
}
else
{
echo "You can't access this directly";
}
When you call the AJAX make sure to include the POST variable and password in your payload. Since it is in POST it will be encrypted, and since it is random (hopefully) nobody will be able to guess it.
If you want to include or require the PHP directly on another page, just set the POST variable to the password before including it.
$_POST["access"] = "makeupapassword";
require("path/to/the/ajax/file.php");
This is a lot better than maintaining a global variable, session variable, or cookie because some of those are persistent across page loads so you have to make sure to reset the state after checking so users can't get accidental access.
Also I think it is better than page headers because it can't be sniffed since it is secured by HHTPS.

You'll probably have to have some kind of cookie-based authentication. In addition, Ignacio has a good point about using POST. This can help prevent JSON hijacking if you have untrusted scripts running on your domain. However, I don't think using POST is strictly necessary unless the outermost JSON type is an array. In your example it is an object.