Help with session_start();

The php web video script that I’m using displays a User’s profile page by simply adding (for example) …/@UserName after the url into a browser. I tried to have a User’s profile page only display to Users who are logged into the site, by adding session_start code:

session_start();
if(!isset($_SESSION['username'])){
   header("Location:../login");
}

after the <?php
to this code:

<?php
if (empty($_GET['id'])) {
    header("Location: " . PT_Link(''));
    exit();
}
$username = PT_Secure($_GET['id']);
$user_id  = $db->where('username', $username)->getOne(T_USERS);

$lists    = false;
if (empty($user_id)) {
    header("Location: " . PT_Link(''));
    exit();
}
$pt->page_url_ = $pt->config->site_url.'/@'.$username ;
$pt->second_page = 'videos';
if (!empty($_GET['page'])) {
    switch ($_GET['page']) {
        case 'liked-videos':
            $pt->second_page = 'liked-videos';
            break;
        case 'about':
            $pt->second_page = 'about';
            break;
        case 'play-lists':
            $pt->second_page = 'play-lists';
            $lists           = true;
            break;

    }
    $pt->page_url_ = $pt->config->site_url.'/@'.$username."?page=".$pt->second_page;
}

$user_data   = PT_UserData($user_id, array(
    'data' => true
));

etc.

but was unsuccessful. The problem is although the …/@UserName no longer displays in the browser field (and redirects to the login page), once logged in the User can’t see his Profile Page either.

Any help with modifying this so that …/@UserName no longer displays in the browser field, but is available to display upon log-in, will be appreciated.

Should be…

if(!isset($_SESSION['username'])){
   header("Location:../login");
   exit;
}

Thanks for your reply.
I added your suggested modification, cleared the browser history, and when https://url.com/@chrisj (for example) is entered into the browser, the profile page no longer displays (and am redirected to login successfully), but still the profile page is unavailable to the logged-in User, when the “Profile” selection is chosen from the drop-down menu (after log-in). The copied link address from the drop-down-menu > Profile is the same https://url.com/@chrisj (for example).

The code is now currently:

<?php
if(!isset($_SESSION['username'])){
   header("Location:../login");
   exit;
}

if (empty($_GET['id'])) {
    header("Location: " . PT_Link(''));
    exit();
}
$username = PT_Secure($_GET['id']);
$user_id  = $db->where('username', $username)->getOne(T_USERS);

$lists    = false;
if (empty($user_id)) {
    header("Location: " . PT_Link(''));
    exit();
}
$pt->page_url_ = $pt->config->site_url.'/@'.$username ;
$pt->second_page = 'videos';
if (!empty($_GET['page'])) {
    switch ($_GET['page']) {
        case 'liked-videos':
            $pt->second_page = 'liked-videos';
            break;
        case 'about':
            $pt->second_page = 'about';
            break;
        case 'play-lists':
            $pt->second_page = 'play-lists';
            $lists           = true;
            break;

    }
    $pt->page_url_ = $pt->config->site_url.'/@'.$username."?page=".$pt->second_page;
}

$user_data   = PT_UserData($user_id, array(
    'data' => true
));

Any additional assistance with modifying this so that …/@UserName no longer displays the profile page after being entered into the browser field, but is available to display while logged-in, is appreciated.

Standard Debugging Protocol #1

error_reporting(-1);
ini_set('display_errors', 1);
2 Likes

Since PHP 7 adding the following to the top of the page throws a warning:

<?php
declare(strict_types=1);
error_reporting (-1);

// Warning, incorrect usage
ini_set('display_errors', 1);

// Correct usage
ini_set('display_errors', 'true');

Correct usage:

  1. Eliminates PHP’s sloppy type juggling
  2. makes the script perform just a little bit faster
  3. Also it fails fast.

https://www.php.net/manual/en/function.ini-set.php

Edit:
I forgot to mention the error log would be smaller - no clogging the logs :slight_smile:

$_SESSION[‘username’]

Is this actually set? Do a print_r($_SESSION)?

Actually it seems the correct usage is somewhere between us. A string containing “1”. Though you’re correct, since 5.2.4 it was a Boolean, now a string.

1 Like

That’s what he checks for in the first part, and if it’s not set, redirects to the login page.

Personally my immediate suspicion for it being blank is a suppressed ‘Headers already sent’ due to whitespace before the PHP tag. (Think horses not zebras… the problem manifested once he added session info.)

Do you have something (a .htaccess rewrite rule for example, I’m not familiar with them myself) that converts your link to contain URL parameters? Just after your new check to see if the session variable is set, you look for $_GET['id'] and I can’t see where that’s coming from in your link, unless you convert @ChrisJ into it somewhere.

Unavailable in what way? Shows the page but doesn’t have any information on it, redirects somewhere, does something else?

Fair point, but he did say that after adding the exit() to the code, it now redirects to the login page correctly. Now the issue is that it’s not doing what it should when the user is logged in.

Except that ‘redirect to the login page’ is the fail-safe action. If the session hasnt been instantiated successfully, $_SESSION[‘username’] will never exist, and so you’d get the behavior the OP describes.

1 Like

Of course! I was thinking of the redirect failing, rather than the session_start().

2 Likes

I know. But is it ever set anywhere? If not, the user will always be redirected to the login page, even if logged in.

It’s hard to tell - he says it’s still “unavailable” even while logged in, but not how it’s unavailable - if it were redirecting in both cases I’d have thought it would be phrased differently. Hopefully @chrisjchrisj will clarify later on.

1 Like

I’m only speculating, but I think it’s a logical problem. If it was a syntactical problem, the errors would have presented themself early on. Since the OP was able to successfully redirect the user if the user wasn’t logged in, the problem now is within the switch statement. I assume maybe it’s because there’s no default case, but the line above the switch statement suggests otherwise. Maybe I’m not seeing it right away, but I’m pretty sure it has to do with the logical side.

@ChrisjChrisj Try to be consistent and use either exit; or exit();, but not both. This won’t fix the problem, but it’ll help you be consistent.

Also, where is $_GET[‘id’] coming from? Is that what you have for your mod_rewrite in your .htaccess file? Something doesn’t seem right with grabbing the id if you don’t have that regex in your .htaccess file.

1 Like

The switch only sets the value of $pt->second_page, which is assigned a value prior to the if that surrounds the switch. So it has a default, which covers it either not being set, or not being one of the values checked for.

1 Like

Thanks for all the replies. Much appreciated.
I tried this:

if(!isset($_SESSION['username'])){
   header("Location:../login");
   print_r($_SESSION);
   exit;
}

and this:

<?php

declare(strict_types=1);
error_reporting (-1);

// Warning, incorrect usage
//ini_set('display_errors', 1);

// Correct usage
ini_set('display_errors', 'true');


if(!isset($_SESSION['username'])){
   header("Location:../login");
   print_r($_SESSION);
   exit();
}


if (empty($_GET['id'])) {
    header("Location: " . PT_Link(''));
    exit();
}

but saw nothing different, and nothing in the error log, and nothing in the Console.
I see nothing in the .htaccess regarding a rewrite about this page.
When selected, after log-in it just seems to refresh the same page.

I went ahead and asked the developer, and he simply said:
“Its happening because file is same so no remedy for now”.

So, now I’m looking for ideas on what I might try as a work around.
Any additional ideas/guidance/comments are appreciated.

Does your application have a rewrite rule pointing and directing requests to a specific page like the index? What confuses me is why you’re requesting for $_GET[‘id’] if you actually want the username. Unless your .htaccess file has a rewrite rule to append all requests to $_GET[‘id’], it doesn’t make sense to be looking for it and then applying it to your database call. What I mean is that if your .htaccess file has a rewrite rule like

RewriteRule ^(.+)$ index.php?url=$1 [QSA,L]

Or whatever it maybe, it doesn’t make sense to use PHP to look for $_GET[‘id’] when what you should be looking for is $_GET[‘url’]. Not saying yours is exactly like this, but I’m just speculating right now.

EDIT: Also, try doing

header('Content-Type: application/javascript;');
print_r($_GET);
exit;

And place it right after your starting PHP tag. Then post the array result here. I have a suspicion.

Much thanks for your reply.

in .htaccess, the closest lines I see to yours are:

RewriteRule ^$ index.php?link1=home [NC,QSA]
RewriteRule ^v/(.*)$ index.php?v=$1 [NC,QSA]
RewriteRule ^([^\/]+)(\/|)$  index.php?link1=$1 [QSA]

Also, I have added your suggested code like so:

<?php
header('Content-Type: application/javascript;');
print_r($_GET);
exit();

if(!isset($_SESSION['username'])){
   header("Location:../login");
   exit();
}

if (empty($_GET['id'])) {
    header("Location: " . PT_Link(''));
    exit();
}
$username = PT_Secure($_GET['id']);
$user_id  = $db->where('username', $username)->getOne(T_USERS);

$lists    = false;
if (empty($user_id)) {
    header("Location: " . PT_Link(''));
    exit();
}
$pt->page_url_ = $pt->config->site_url.'/@'.$username ;
$pt->second_page = 'videos';
if (!empty($_GET['page'])) {
    switch ($_GET['page']) {
        case 'liked-videos':
            $pt->second_page = 'liked-videos';
            break;
        case 'about':
            $pt->second_page = 'about';
            break;
        case 'play-lists':
            $pt->second_page = 'play-lists';
            $lists           = true;
            break;

    }
    $pt->page_url_ = $pt->config->site_url.'/@'.$username."?page=".$pt->second_page;
}

but see no results. The same page appears with no changes that I can see.

any additional comments are appreciated