Project

General

Profile

Bug #4552

Incorrect protocol (http/https) in link created by javascript code

Added by Bas Wijnen over 7 years ago. Updated over 7 years ago.

Status:
Bug resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
23/03/2012
Due date:
% Done:

100%

Estimated time:
Spent time:
Complexity:
Normal
SCRUM pts - complexity:
?

Description

In main/course_home/[vertical_]activity.php the variable $current_protocol is set to something built from $_SERVER['SERVER_PROTOCOL']; This leads to $server_protocol being set to HTTP://, where HTTP comes from the HTTP/1.0 (or similar) reply that the server gives.

However, the server gives this reply also when approached over https. This variable is used (as my_protocol) in main/inc/lib/javascript/glossary.js to build a path for indicator.gif.

The problem here is that it will always link to the http version of the icon. On my system, this is a bigger problem than usual, because Chamilo can only be approached on https. So the icon is not actually available over https. This means that it results in a 404, which somehow makes the page say something like "this is an encrypted page with unencrypted parts, data may not be securely transmitted". I don't want my users to see this (unless it is really true). So I want use the actual protocol, or a relative link (but since this is a library, a relative link may not be feasable, with the directory depth from the source page being variable. Not sure about that though. A relative link is certainly the best solution, if it is possible).

On my system, I have simply overridden server_protocol with 'https', but this is not a usable solution, of course.

Associated revisions

Revision dd882792 (diff)
Added by Julio Montoya over 7 years ago

Cleaning unused variables see #4552

History

#1

Updated by Julio Montoya over 7 years ago

  • Status changed from New to Needs more info
  • % Done changed from 0 to 20

I checked the code in chamilo 1.9 and apparently the variable is not used (I should delete it) $path_work

    $current_protocol = $_SERVER['SERVER_PROTOCOL'];
    $current_host = $_SERVER['HTTP_HOST'];
    $server_protocol = substr($current_protocol, 0, strrpos($current_protocol, '/'));
    $server_protocol = $server_protocol.'://';
    if ($current_host == 'localhost') {
        // Get information of path
        $info = explode('courses', api_get_self());
        $path_work = substr($info[0], 1);
    } else {
        $path_work = '';
    }

I also found that we call "glossary.js" but we use the api_get_js('glossary.js') wich uses the api_get_path(WEB_LIBRARY_PATH) function
see the function in main_api.lib.php:

function api_get_js($file) {    
    return '<script type="text/javascript" src="'.api_get_path(WEB_LIBRARY_PATH).'javascript/'.$file.'"></script>'."\n";
}
#2

Updated by Julio Montoya over 7 years ago

  • % Done changed from 20 to 80
#3

Updated by Bas Wijnen over 7 years ago

This comment is based on a repository checkout, I didn't actually test it, since the checkout isn't hosted as https.

I see it has been removed from glossary.js (it has been changed into a relative link).

A grep on the repository leaves two places where $server_protocol is used:
- in main/course_home/[vertical_]activity.php. It is set to a buggy value here.
- in main/inc/lib/main_api.lib.php. This is a different (local) variable, which is used for stuff during the installation. It is set to a correct value here, it seems, and used properly.

This means that the bug is indeed fixed, by not using the variable anymore. It would be good to remove its buggy definition from main/course_home/activity.php and main/course_home/vertical_activity.php as well, so nobody will introduce the bug again by using it.

#4

Updated by Julio Montoya over 7 years ago

  • Status changed from Needs more info to Bug resolved
  • % Done changed from 80 to 100

Great! I just removed that code

Also available in: Atom PDF