简体   繁体   中英

Datatables - Using Ajax datasource (sAjaxSource) with multiple tables and dynamic argument

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!

https://softwareengineering.stackexchange.com/questions/216605/how-do-web-servers-enforce-the-same-origin-policy

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.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM