Project

General

Profile

Feature #6201

Unique portal identifier for better stats

Added by Yannick Warnier over 5 years ago. Updated almost 3 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
Global / Others / Misc
Target version:
Start date:
07/06/2013
Due date:
% Done:

0%

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

Description

We are starting to have problems with the stats. Many portals are registering twice or thrice, which makes it impossible to really estimate our worldwide community (currently there are approximately 2M users too much in the count, as far as I can estimate).
This is due to portals using different names over time. For example, http://campus.chamilo.org and https://campus.chamilo.org are the same portal, only that now we use https for it. It is registering twice, so we're off by 220,000.

One good way to avoid this would be to generate a unique hash key by portal from now on, so when a portal sends us the information, it can also send its key and we know (even if it comes under two different names).
Of course, this won't be a solution straight away, but if we store this setting in the database, we can easily include it in the upgrade procedure and make sure there is one single unique key for each multi-url on a multi-url installation.

Having a unique hash can be relatively easily done by using sha1 on a random or pseudo-random value. For example, we could use a concatenation of the first root_web param, the sys_root, the url (multi-url, if any) and a random number (on 999,999,999) to generate it.
We cannot use the security_key for that, as it's secret.

Something like this:

$url = api_get_access_url(api_get_current_access_url_id());
sha1($_configuration['root_web'].$_configuration['root_sys'].$url['url'].rand(0,999999999))

History

#1

Updated by Yannick Warnier almost 3 years ago

  • Target version changed from 2.0 to 3.0

Also available in: Atom PDF