Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5

Shoutbox : comment récupérer des informations d'appli tiers
#1

Salut tout le monde, j'ouvre ce topic au sujet de mon module Shoutbox dans sa version actuelle 1.2.1

J'ai reçu une demande d'évolution qui est loin d'être débile : ajouter la possibilité de linker le pseudo de la shoutbox au login utilisé dans FEU.

J'aimerais un coup de main par ce que
- j'ai pas vraiment le temps sur ce coup
- j'aimerais inclure d'autre liens de connexion depuis d'autres application : fluxBB (ouais un chat ici même ! ) mais également phpBB dans un premier temps.

L'idée étant de conserver un paramètre simple :

{monTag appliLink="FEU|PHPBB|FLUXBB"}


Auriez vous des pistes pour moi sur la gestion des connexions via la session / les cookies de ces applications ?

merci d'avance Wink
Répondre
#2

Pour palier à cette fonctionnalité absente, j'avais simplement rajouté avant l'appel à la Shootbox une balise utilisateur :
Code :
$_SESSION[Shootboxauthor] = $username ;
En fait je récupérais le $username grâce à une requête sur mon forum en me basant sur la variable de session du dit forum.

Quasiment chaque système de gestion de forum utilise une table "sessions" où l'on peut trouver l'ID de l'utilisateur et par conséquent son nom ou pseudo.
Néanmoins il faut souvent lire avant un cookie pour obtenir l'ID de la session.

Personnellement j'ai testé avec vBulletin et SMF. Mais ça devrait être valable pour à peu près tous.

Pour l'appel à ta shootbox il faudrait deux variables pour s'assurer un max de compatibilité.
Genre :
extApps="VBULLETIN|SMF|PHPBB"
extAppsVersion = "1.0|2.0RC3|4.7"

Et créer une classe permettant la gestion des applications et leurs versions.

Mais je pense également qu'il pourrait être utile d'en rajouter une dernière (de variable) telle que :
username=$mavariable
Permettant à ceux qui veulent intégrer l'username de leur choix de le faire. Je pense par là à une équipe rédactionnelle qui est susceptible de s'identifier sous plusieurs pseudos mais souhaitant répondre au nom de l'entreprise.

Sinon je n'ai malheureusement pas de temps à t'offrir en ce moment. J'ai deux projets à boucler pour cette fin de semaine et j'entame la réalisation d'un extranet dans la foulée.
Répondre
#3

L'idée de rendre interopérable me plais beaucoup mais laisse supposer que l'on laisse une grande marge de manœuvre aux utilisateurs et donc d'ajouter un panel admin pour gérer tout ca.

une série de pré-paramétrage mais la possibilité aussi de laisser l'utilisateur tout configurer :

nom du cookies
nom de la variable dans le cookies représentant le SID
préfixe des bases du forum ( + en optionnel les codes d'accès à la bdd du forum)

et de l'autre côté il va falloir créer une librairie de compatibilité de connexion aux différents modules et version disponibles...

bref saoulant avant même d'être entamé...

en fait il ferrait un module à lui seul ! permettre de récupérer l'utilisateur d'un logiciel Tiers actif dans CMSMS

je crois qu'on va juste rester sur l'idée d'ajouter le lien vers FEU pour l'instant et voir dans le futur pour gérer un module dédié aux connexions externes
Répondre
#4

On pourrait faire quelque chose d'assez simple pour récupérer le nom d'utilisateur à afficher avant de poster dans la shootbox.

On pourrait charger à la demande (grâce à une fonctionnalité dans le panneau d'admin) un fichier de classes php. L'utilisateur averti ou la communauté pourrait alors créer ces fichiers classes en fonction des gestionnaires de forums existants.

Je m'explique et prend pour exemple vBulletin 3.7.
Je créé un fichier class.vbulletin-3.7.php dans le répertoire du module.

Le script de la shootbox va chercher un fichier nommé class.*.php et stocke dans la variable $forum_class le nom du fichier (sans extension) et le charge :
Code :
require_once('class.' . $forum_class . '.php') ;
Ce fichier comportera une seule fonction "static" : UserReturn()

Et le script de la Shootbox lancera l'appel à cette fonction par :
Code :
$shootbox_user = call_user_func($forum_class .'::UserReturn');
Le script récupère alors simplement le nom d'utilisateur.

Si aucun fichier class ou si le retour de la fonction renvoi "null" alors on affiche un input text pour saisir son pseudo.

Toute la partie "compliquée" de récupération du pseudo est décentralisée dans chaque fichier class.*.php
La communauté de développeur aura ainsi la possibilité de faire évoluer la shootbox grâce à un fichier.

Si à terme le module se voit doté de 10 fichiers classes différents, il suffira par défaut de les nommer "_class.*.php" et de supprimer le premier underscore pour activer la classe choisie.

Ca te semble plus simple ou pas ?
Répondre
#5

d'autres soucis en perspective :

Citation :Quasiment chaque système de gestion de forum utilise une table "sessions" où l'on peut trouver l'ID de l'utilisateur et par conséquent son nom ou pseudo.
et si la base du forum ne se trouve pas sur la même que celle de CMSMS ?

il faudrait que le module de CMS aille chercher le fichier de config du forum, le lise et s'en serve pour se connecter lui même. Pour que ca marche il faudrait que l'utilisateur donne l'url du forum.

concernant ton système de fichier externalisé j'aime plutôt bien, je préfère toute fois éviter qu'un utilisateur aille trifouiller les fichiers de son FTP. Du coup on peut prévoir de mettre à disposition X fichier de connexions sous la forme de class.NomForum-Version.php que l'utilisateur uploadera directement dans l'interface du module. Il aura donc le choix d'uploader tel ou tel connecteur. Il obtient également une liste qu'il sélectionnera pour désigner le connecteur utilisé

- Empty : option par défaut,
- FEU : installé avec le module, permet la connexion depuis le module FEU
- ... la liste des type de connexion disponible.

Ainsi la mise à jour d'un forum serait aisé : je met à jour mon forum, j'upload le nouveau fichier de connexion, je sélectionne la nouvelle connexion et c'est repartit.

Une correction d'un bug dans un fichier de connexion suivra le même chemin : upload de la nouvelle version de fichier de connexion, il écrase l'ancien fichier présent et c'est repartit.
Répondre
#6

Pour le problème de connexion, on peut imaginer que le action.defaultadmin.php charge les fichiers class.*.php et créé un onglet spécifique avec un formulaire pour saisir les informations de connexion avec un enregistrement en base de données.

Il faudrait réfléchir à ce système en détails mais le fait d'utiliser des fichiers séparés me semble être la solution la plus modulable. C'est d'ailleurs celle que j'utilise sur certains modules pour des clients.
Répondre
#7

D'ici le moment ou je recoderais tout au propre j'ai déjà la solution pour modifier la version 1.2.1 et la lier à FEU

Ouvrir le fichier Shootbox.module.php dans le répertoire /module/shootbox

trouver :

Code :
if (isset($_SESSION[$sessionAuthor]) && $_SESSION[$sessionAuthor] != "")
ajouter avant :

Citation :$gCms =& $GLOBALS["gCms"];


//Si le module FEU est installé et qu'une personne est logguée on récupère son pseudo
if( isset( $gCms->modules['FrontEndUsers'] )
&& isset( $gCms->modules['FrontEndUsers']['object'])
&& $gCms->modules['FrontEndUsers']['object']->LoggedInId() != null)
{
$feuModule = $gCms->modules['FrontEndUsers']['object'];

$user_properties = $feuModule->GetUserProperties($feuModule->LoggedInId());

$login = null;

//On récupère le pseudo de la personne
foreach ($user_properties as $user_propertie)
{
if($user_propertie["title"] == "pseudo") // Choice the name of the user's property to show
{
$login = $user_propertie["data"];
break;
}
}

if($login == null)
{
$login = $feuModule->LoggedInId();
}

$_SESSION[$sessionAuthor] = $login;

return "<div id=\"shootboxDiv\">
<span id=\"shootboxNickname\">".$_SESSION[$sessionAuthor]." : </span>
<span id=\"shootboxSpan\">".$this->CreateInputText ($this->GetName(), 'input', null, null, 500)."</span>
".$this->_getCredit()."
</div>";
}
Enregistrer

Changer "pseudo" pour le nom de la propriété FEU que vous souhaitez voir afficher


me prévenir en cas d'emmerde Wink
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)