beurk les cookies

Répondre
 
Partager Rechercher
Code PHP:

<?
    setcookie("password",$password,time()+3600);
?>
Code PHP:

string URL="http://magic.cat.free.fr/cookie.php?";
default
{
    touch_start(integer total_number)
    {
      
        llHTTPRequest(URL + "password=toto",[HTTP_METHOD,"POST"],"");     
    }
} 
Voila un script PHP et un script LSL
L'objectif pour moi est de stocker une valeur dans un cookie grace à la page PHP.
La page PHP semble marcher car quand je click sur les lien "à la main" ca marche.

Mais via le script LSL rien à faire, ca fait rien pas de message d'erreur, rien...
Une idée?
Lien direct vers le message - Vieux 08/02/2009, 20h06
Quelle drôle d'idée !

Ceci dit les informations de retour du cookie de la part du client doit se trouver dans un en-tête de la requête comme par hasard appelée Cookie. Donc le fait de mettre tes valeurs dans l'introduction de ta requête ne peut pas fonctionner.

Par exemple le serveur a envoyé l'en-tête suivant :
Set-Cookie : id=toto

En retour la requête du client doit comporter la même en-tête :
Cookie : id=toto

Les navigateurs savent bien générer ces en-têtes, par contre au niveau de la fonction llHTTPRequest je n'ai pas vu cette possibilité. Mais je t'avoue que je n'ai jamais pensé à bidouiller une requête à ce point.
Lien direct vers le message - Vieux 08/02/2009, 21h59
Citation :
Publié par Magic Cat
Code PHP:

<?
    setcookie("password",$password,time()+3600);
?>
Code PHP:

string URL="http://magic.cat.free.fr/cookie.php?";
default
{
    touch_start(integer total_number)
    {
      
        llHTTPRequest(URL + "password=toto",[HTTP_METHOD,"POST"],"");     
    }
} 
Voila un script PHP et un script LSL
L'objectif pour moi est de stocker une valeur dans un cookie grace à la page PHP.
La page PHP semble marcher car quand je click sur les lien "à la main" ca marche.

Mais via le script LSL rien à faire, ca fait rien pas de message d'erreur, rien...
Une idée?
tu as fais deux erreurs...

la première d'oublier de récupérer la variable passée.

Code PHP:

<?php
$pass =  $_GET['password'];
echo $pass;
?>
la seconde est liée à l'utilisation des cookies en php.
  • Les cookies ne seront accessibles qu'au chargement de la prochaine page, ou au rechargement de la page courante. Pour tester si un cookie a été défini avec succès, vérifiez la présence du cookie au prochain chargement de la page avant que le cookie n'expire. Le délai d'expiration est défini en utilisant le paramètre expire . Une façon simple de vérifier le positionnement du cookie est d'utiliser print_r($_COOKIE);.
Code PHP:

string  URL="http://magic.cat.free.fr/cookie.php?password=toto";

key     http1;

default
{
    touch_start(integer total_number)
    {
      
        http1 = llHTTPRequest(URL, [HTTP_METHOD, "POST"],"");     
    }

    http_response(key id,integer status, list meta, string body)
    {
        if (id == http1) 
        {
            if (status < 300)  
            {
                llOwnerSay ( "Le serveur a répondu: " + body );
            }
            else
                llOwnerSay ( "Erreur sur le serveur: " + (string) status);
        }
    }
} 
Lien direct vers le message - Vieux 08/02/2009, 23h27
Ta première erreur est de croire que j'en ai fait une

Je montre ici que un exemple simpliste de ce que je veux faire qui est pour une architecture beaucoup plus complexe.
j'ai besoin de mon cookie, mais j'ai pas besoin de récupérer ma variable.
Une autre page s'en chargera ultérieurement via le cookie, c'est là l'objectif.
Lien direct vers le message - Vieux 08/02/2009, 23h40
bon je vais expliquer le tout ca sera plus simple pour comprendre mon choix de passer par des cookies.

j'ai tout un ensemble de variable dans mon script qui sont paramètrables par l'utilisateur.
SL n'etant pas riche en interface pour la saisie ou autre, j'ai pensé à externaliser la saisie de la manière suivante:
- 1 je fais une request vers une page php qui sauve toutes mes variable dans des cookies
- 2 Via un loadURL j'ouvre une autre page web avec un formulaire qui se sera charger via les cookies.
- 3 L'utilisateur saisie et modifies les variable puis il envoit et les variables sont à nouveau stocké dans les cookies
- 4 via un XML-RPC j'indique à mon script que les données on été modifiée et sont prete.
- 5 via une request encore je consulte une page web qui renvoit le contenu des cookie.
- 6 je charge le contenu recu dans mes variables.


Pourquoi un choix si compliqué?
Je pourrais envoyer mes donner à une page PHP avec un formulaire qui me reverrait le tout par XML-RPC et j'aurais tout fait en une fois. Mais c'est sans compter la limitation du llloadURL et du RPC limité à 255 caractères.

Je suis daccord c'est tordu mais ca marche super bien "à la main" dans un navigateur et pas via ce P.. de M... de LSL
Lien direct vers le message - Vieux 09/02/2009, 00h25
...
Lien direct vers le message - Vieux 09/02/2009, 00h28
LSL, comme tout les "langages " a ses points forts et ses points faibles... Pour certaines choses, il est même plutôt limité...

@le chat magique : tu peux expliquer à une profane à quoi sert le fruit de tes cogitations ? J'avoue humblement que j'ai toujours pas compris l'intérêt de ces liens entre sites web et SL (à part pour le loadURL ^^) ?
Lien direct vers le message - Vieux 09/02/2009, 08h21
Je fais ca pour palier à un des grands point faible du LSL le manque d'IHM

Dès que l'on a pas mal d'option que l'utilisateur a le droit de gérer ca devient un peu le bordel. Des popup bleu et sous popup bleus dans tout les sens a plus rien y comprendre
Pis alors des que l'on veut de l'écrit c'set encore pire, genre pour de la saisie de message. Ben il faut soit une notecard soit un listen ou tu tapes dans le clavier.
Tiens la config par notecard parlons
c'est peut etre la moinsse pire des solutions, et pourtant y a tout de même toute une usine derrière a ecrire pour que ca marche ente les detection de nom de variable, les transtypages, l'algorythme "anti-abruti qui saisi n'importe quoi" et bien d'autres joyeuseries.

Bon donc, je me suis dis on a acces au oueb, tres bien je vais me faufilé par là.
Objectif utiliser des formulaires que l'on utilise HTML.
Avec le web on peut faire des formulaire de saisie super puissant et convivial.
C'set la pas les adeptes du "client léger" qui me contrediront

Resultat des courses pour le script?
Certes, y a une grosse gestion derrière, mais bien ecrit c'est réutilisable. Un petit peu comme menu popup avec les "<<" ">>"
Mais là, ca serait vraiment géant pour l'utilisateur d'avoir un truc beau personnaliser où y a des boutons, des zone de texte, de boutons radio toussa toussa
Lien direct vers le message - Vieux 09/02/2009, 08h59
Euh t'as essayé de mettre "?password=toto" au lieu de juste "password=toto" ??

Et de passer ça en GET plutot qu'en POST??

J'avais fais ça et ça marchait bien... faut juste que je retrouve mon LSL IG ... vers midi je pense
Lien direct vers le message - Vieux 09/02/2009, 09h28
Déjà dans un premier temps comment fonctionnent les cookies :

1. Je fais une requête HTTP auprès du serveur.
2. Le serveur HTTP génére une réponse, y adjoint un cookie, et me renvoie la réponse.
3. Mon navigateur réceptionne la réponse et copie le cookie sur ma machine.
4. Je fais une deuxieme requete et renvoie le cookie créé precedemment.
5. Le serveur genere une reponse, modifie le cookie et me renvoie le tout.
6. Mon naviagateur réceptionne la réponse et le cookie modifié.

Maintenant ce qui se passe :

Tu cliques sur ton objet et celui ci transmet sa config via llHttpRequest. A ce moment là c'est le simulateur le client du serveur. Le serveur genere bien le cookie et l'envoie au simulateur.
Ensuite tu rediriges, l'utilisateur a l'intermediaire de son navigateur sur la page de configuration. Hors ici, le client a changé c'est l'utilisateur et non plus le simulateur. Grosso - modo le cookie a disparu...
Donc ce qu'il va falloir faire ici, dans un premier temps c'est ne pas avoir faim (les cookies c'est bon mangez en), et secondo trouvez un autre moyen de transmettre la configuration...

Cela dit, je te rassure, c'est largement possible...
Lien direct vers le message - Vieux 09/02/2009, 09h35
En complément de Gontineac le client ( le navigateur ) s'exécute sur la machine de l'utilisateur.

Les scripts tel que Java, ActiveX etc. , et les codes HTML, CSS etc sont exécutés ou interprétés coté client.

Le code PHP s'exécute du coté serveur.

La confusion est très souvent faite.
Lien direct vers le message - Vieux 09/02/2009, 10h17
Citation :
Publié par Magic Cat
Je fais ca pour palier à un des grands point faible du LSL le manque d'IHM

Dès que l'on a pas mal d'option que l'utilisateur a le droit de gérer ca devient un peu le bordel. Des popup bleu et sous popup bleus dans tout les sens a plus rien y comprendre
Pis alors des que l'on veut de l'écrit c'set encore pire, genre pour de la saisie de message. Ben il faut soit une notecard soit un listen ou tu tapes dans le clavier.
Tiens la config par notecard parlons
c'est peut etre la moinsse pire des solutions, et pourtant y a tout de même toute une usine derrière a ecrire pour que ca marche ente les detection de nom de variable, les transtypages, l'algorythme "anti-abruti qui saisi n'importe quoi" et bien d'autres joyeuseries.

Bon donc, je me suis dis on a acces au oueb, tres bien je vais me faufilé par là.
Objectif utiliser des formulaires que l'on utilise HTML.
Avec le web on peut faire des formulaire de saisie super puissant et convivial.
C'set la pas les adeptes du "client léger" qui me contrediront

Resultat des courses pour le script?
Certes, y a une grosse gestion derrière, mais bien ecrit c'est réutilisable. Un petit peu comme menu popup avec les "<<" ">>"
Mais là, ca serait vraiment géant pour l'utilisateur d'avoir un truc beau personnaliser où y a des boutons, des zone de texte, de boutons radio toussa toussa
Merci le chat... come d'hab, tu es magique
Lien direct vers le message - Vieux 10/02/2009, 09h46
Miammmm les cookies, moi je les croque au petit déj...

ok je sors .... heu non je reste

Citation :
Publié par Magic Cat
Je fais ca pour palier à un des grands point faible du LSL le manque d'IHM

Dès que l'on a pas mal d'option que l'utilisateur a le droit de gérer ca devient un peu le bordel. Des popup bleu et sous popup bleus dans tout les sens a plus rien y comprendre
Pis alors des que l'on veut de l'écrit c'set encore pire, genre pour de la saisie de message. Ben il faut soit une notecard soit un listen ou tu tapes dans le clavier.
Tiens la config par notecard parlons
c'est peut etre la moinsse pire des solutions, et pourtant y a tout de même toute une usine derrière a ecrire pour que ca marche ente les detection de nom de variable, les transtypages, l'algorythme "anti-abruti qui saisi n'importe quoi" et bien d'autres joyeuseries.

Bon donc, je me suis dis on a acces au oueb, tres bien je vais me faufilé par là.
Objectif utiliser des formulaires que l'on utilise HTML.
Avec le web on peut faire des formulaire de saisie super puissant et convivial.
C'set la pas les adeptes du "client léger" qui me contrediront

Resultat des courses pour le script?
Certes, y a une grosse gestion derrière, mais bien ecrit c'est réutilisable. Un petit peu comme menu popup avec les "<<" ">>"
Mais là, ca serait vraiment géant pour l'utilisateur d'avoir un truc beau personnaliser où y a des boutons, des zone de texte, de boutons radio toussa toussa
Mouiii - Moi je n'aime pas les interfaces LSL-web parceque j'ai horreur de sortir de SL quand j'y suis. Et puis il me plait d'imaginer que mes objets me survivront dans SL, ce qui ne sera pas le cas s'ils sont tributaires d'un site web que je ne maintiendrais plus.
Aussi pour ton cas (que je connais un peu) je me tournerais vers soit:
La config par notecard: depuis mes débuts, j'utilise ce script trouvé en freebie qui est béton : la notecard supporte des commentaires commençant par #, ce qui permet d'y mettre en clair la signification des paramétres, et après tout s'écrit sous la forme paramétre=valeur; c'est assez béton car un faux paramétre est ignoré, et un paramétre manquant prend sa valeur par défaut.
Code:
string notecard_name = "configuration";  // name of notecard goes here

// internals
integer DEBUG = FALSE;
integer line;
key queryhandle;                   // to separate Dataserver requests
key notecarduuid;

init()
{
    queryhandle = llGetNotecardLine(notecard_name, line = 0);// request line
    notecarduuid = llGetInventoryKey(notecard_name);
}

// Config data loaded from notecard, with some sane defaults
integer channel = 1000;
string email_address = "revolution.perenti@skidzpartz.com";
default
{
    changed(integer change)         
    {
        // We want to reload channel notecard if it changed
        if (change & CHANGED_INVENTORY)
            if(notecarduuid != llGetInventoryKey(notecard_name))
                init();
    }

    state_entry()
    {
        init();
    }
    
    dataserver(key query_id, string data)
    {
        if (query_id == queryhandle)
        {
            if (data != EOF)
            {   // not at the end of the notecard
                // yay!  Parsing time
                
                // pesky whitespace
                data = llStringTrim(data, STRING_TRIM_HEAD);

                // is it a comment?
                if (llGetSubString (data, 0, 0) != "#")
                {
                    integer s = llSubStringIndex(data, "=");
                    if(~s)//does it have an "=" in it?
                    {
                        string token = llToLower(llStringTrim(llDeleteSubString(data, s, -1), STRING_TRIM));
                        data = llStringTrim(llDeleteSubString(data, 0, s), STRING_TRIM);

                        //Insert your token parsers here.
                        if (token == "email_address")
                            email_address = data;
                        else if (token == "channel")
                            channel = (integer)data;
                    }
                }

                queryhandle = llGetNotecardLine(notecard_name, ++line);
                if(DEBUG) llOwnerSay("Notecard Data: " + data);
            }
            else
            {
                if(DEBUG) llOwnerSay("Done Reading Notecard");
                state configuration ;
            }
        }
    }
}

state configuration
{
 
    state_entry()
    {
        llListen(channel, "", "", "");
        llShout(0, "Channel set to " + (string)channel);
        llShout(0, "Email set to " + (string)email_address);
    }   
}
Ensuite, si tu préfére un cliquodrome, et bien moi je ferais un bon gros hud a attacher en center: le seul problème est la saisie de texte (bouhhhh à quand la llTexBox) faut passer par le chat; pour les chiffres, on peut faire avec des afficheurs (j'ai de très jolis afficheurs 2 chiffres LED ou LCD avec les textures; le texte flottant marche mieux mais est moins beau) et des fléches de défilements décade par décade. Je pense que c'est la solution dans ton cas.
Un très bon exemple de hud complexe http://uncensored.xstreetsl.com/modu...&ItemID=674134

Je pense qu'il faut plutot réserver l'usage du web quand on a besoin de mémoriser et de traiter des données en dehors de SL: soit des traitements complexes, soit de grandes quantités de données.
Lien direct vers le message - Vieux 10/02/2009, 14h42
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés
Thème visuel : Fuseau horaire GMT +2. Il est actuellement 07h21.
^^ Haut de page ^^