Restrict access to serverside processing json response?

98whiskers

Hi community!

First off, apologies if this is a naive question, I've looked through the forum and the docs but as I'm not very experienced I might have missed a very obvious solution.

On my website I'm using datatables to render a large table of customer data and want to use server-side processing for it. There is a login to prevent outside access to the data with a Session variable being set on login.

Now I want to prevent that someone can view the json response page by manually changing the header, via a redirect or no echo if the session login is empty. How can I do that? My first instinct was to just set an if around the echo

if (isset($_SESSION['user'])){
    echo json_encode(
        SSP::simple( $_GET, $sql_details, $table, $primaryKey, $columns )
    );
}

but that just causes the datatables to not load at all anymore. I feel like there's such an obvious answer but I'm somehow missing it.

Any pointing into the right direction would be appreciated!

Datatable configuration:

$(document).ready(function() {

    var table = $("#kundendaten").DataTable( {
        "columns": [
            null,
            null,
            null,
            null,
            null,
            null,
            null,
            null,
            null
        ],
        columnDefs: [
            {
                "data": 3,
                render: (data, type, row) => data + " " + row[4] + " " + row[5],
                targets: 3
            },
            { visible: false, targets: [4, 5] }
        ],
        ajax: 'include/loadKundendaten.inc.php',
        processing: true,
        serverSide: true,
        "language": {
            "lengthMenu": "_MENU_ Einträge pro Seite",
            "zeroRecords": "Keine Datensätze gefunden!",
            "infoEmpty": "Keine Datensätze gefunden!",
            "search": "Suche:",
            "paginate": {
                "first":      "Erste",
                "last":       "Letzte",
                "next":       "  >",
                "previous":   "<  "
            }
        },
        "bLengthChange": false,
        "order": [1, "desc"]
    } );

allan

Now I want to prevent that someone can view the json response page by manually changing the header, via a redirect or no echo if the session login is empty.

Assuming that the user should be able to see that JSON rendered in the DataTable, then there is no way to prevent that. If the browser can read it, then the user can as well. Perhaps the closest you could get is rate limiting to reduce scraping).

If there are rows that the end user shouldn't be able to access though, then you need to block them from the JSON response.

Allan

98whiskers

@allan Hi Allan!

I meant as in it shouldn't be accesible if a user is not logged in. That the json output doesn't happen unless I know a correct login happened via preferably a session variable. If a user is logged in it doesn't matter if they can see the response or not.

I hope that makes more sense!

allan

It sure does, thanks for the clarification. You personally have login check code somewhere else, just use that at the top of the SSP script as well. Usually you'd be checking for a username name in a session variable or something like that? If not found bail out.

Allan

98whiskers

Hi again @allan,

thanks for response but unfortunately I have to bother you one more time,,

As I said in the first Post, I wanted to just check if the session varible isset or not, since all users can access the data, it only matters if a login happened.

If I set the check in the ssp class or on the output page, no matter where, in its own function or around the simple function the datatable stops rendering or shows empty.

The json data still exists and looks the same if the isset() check is there or not. If nobody is logged in it's also empty as intended.

but the table is either empty

or shows an invalid json response error. The GET header is identical both times as well.

This is what confuses me since it does execute when logged in and doesn't when not as intented but then just fails at showing the data.

I tried:
- check before calling the json function
if (isset($_SESSION['user'])){ echo json_encode(SSP::simple( $_GET, $sql_details, $table, $primaryKey, $columns )); }
- set check inside simple function

static function simple ( $request, $conn, $table, $primaryKey, $columns )
    {
        if (isset($_SESSION['user'])){
            $bindings = array();
            $db = self::db( $conn );

            // Allow for a JSON string to be passed in
            if (isset($request['json'])) {
                $request = json_decode($request['json'], true);
            }

                        [...]

            /*
            * Output
            */
            return array(
                "draw"            => isset ( $request['draw'] ) ?
                    intval( $request['draw'] ) :
                    0,
                "recordsTotal"    => intval( $recordsTotal ),
                "recordsFiltered" => intval( $recordsFiltered ),
                "data"            => self::data_output( $columns, $data )
            );
        }
    }

• set check at top of ssp class file as it's own thing.

Any idea why it doesn't work? I'm really not sure where to look since the json looks fine and the check itself does work.

allan

Okay, if all you are doing is looking for a user session variable, what I would put at the top of the SSP script is:

if ( ! isset( $_SESSION['user'] ) ) {
  echo json_encode([
    "error" => "Not logged in"
  ]);
  exit;
}

What I'm a little confused about is your description of multiple users logging in and access tho. A session parameter is per user. Once a user has logged in, they would then have access to that SSP script's data, but no one else (well, until they also logged in).

Allan

98whiskers

Hi @allan,

don't pay too much mind to my description. not a native speaker so it might just be badly worded, I know the session parameter is per user.

Either way, many thanks for taking your time to respond!

It initially threw the same issues with that code but I finally got it fixed, there were issues with the Session itself not working correctly. Sorry to have bothered you, have a nice day.

allan

Awesome - delighted to hear you got it working!

Allan