I have two datatables that I am trying to populate with data via a GET request to a flask API. My datasource url is localhost:5000/data but I am unable to get datatables to display the data. When I create a static .txt file, I can get the data to come through. I looked at my GET request and it looks like it is being appended with some sort of event id from jQuery (I am pretty new to this...). I would eventually like to be able to pass a custom argument to the GET request in order to filter the second table based on which row in the first table is clicked on by the user.
I have experimented with both aaData and sAjaxSource and I cannot get either one to work.
My JSON object is this form:
{
"items": [
{
"column1": "Foo",
"column2": "Bar",
"column3": "1.54"
},
{
"column1": "Blah",
"column2": "Tah",
"column3": "1.54"
}
]
}
Table 1 - I am using a static .txt file and this table displays fine
$(document).ready(function() {
$('#table1').dataTable( {
"bProcessing": true,
"sAjaxSource": "/thisWorks.txt",
"sAjaxDataProp": "item",
"aoColumns": [
{
"mData": "column1"
},
{
"mData": "column2"
},
{
"mData": "column3"
}
]
} );
$('#example tbody').on('click', 'tr', function () {
var clickId = $('td', this).eq(0).text();
} );
Table 2 - Can't get this one to work
$('#table2').dataTable( {
"bProcessing": true,
"sAjaxSource": "http://localhost:5000/data?column1=1234",
"sAjaxDataProp": "items",
"aoColumns": [
{ "mData": "column1" },
{ "mData": "column2" },
{ "mData": "column3" }
]
} );
When I look in my chrome console, I see my second Ajax request being interpreted as something like:
http://localhost:5000/data?column1=1234&_1412145757890
Eventually, I would like to pass the value of clickId from my first table to the Ajax source in my second table so any guidance there would be appreciated.
Thanks!
The same origin policy is a wholly client-based restriction, and is primarily engineered to protect users, not services. All or most browsers include a command-line switch or configuration option to to turn it off. The SOP is like seat belts in a car: they protect the rider in the car, but anyone can freely choose not to use them. Certainly don't expect a person's seat belt to stop them from getting out of their car and attacking you (or accessing your Web service).
Suppose I write a program that accesses your Web service. It's just a program that sends TCP messages that include HTTP requests. You're asking for a server-side mechanism to distinguish between requests made by my program (which can send anything) and requests made by a browser that has a page loaded from a permitted origin. It simply can't be done; my program can always send a request identical to one formed by a Web page.
The same-origin policy was invented because it prevents code from one website from accessing credential-restricted content on another site. Ajax requests are by default sent with any auth cookies granted by the target site. For example, suppose I accidentally load http://evil.com/ , which sends a request for http://mail.google.com/ . If the SOP were not in place, and I was signed into Gmail, the script at evil.com could see my inbox. If the site at evil.com wants to load mail.google.com without my cookies, it can just use a proxy server; the public contents of mail.google.com are not a secret (but the contents of mail.google.com when accessed with my cookies are a secret).
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.