quixote(parte7)

Trattiamo adesso dei cookie.

Il solito metodo di una classe tipo Directory():

def test_cookie(self):

content=(”)

#Anche per la gestione dei cookie bisogna creare un oggetto SessionManager()


manager=get_session_manager()

#Questo sotto con config è un modo di accedere alle variabili settate nel file di configurazione

#di Quixote config.py .In questo caso lo usiamo per tornare il nome prefisso delle sessioni di

#Quixote.

config = get_publisher().config
cookie_name=config.session_cookie_name#nome del cookie costante stringa di config.py

#Questo sotto per vedere se c’è una sessione attiva

content+=htmltext(‘<h5>get_session(prima di revoke) —> %s</h5>’)% get_session()
if manager.has_session_cookie():#se abbiamo un cookie di sessione sul client..

id = get_cookie(cookie_name)#Settiamo l identificativo del cookie

#Diamo in output il nome ed il value (id) del cookie

content+=htmltext(‘<h5>id di get_cookie %s—> %s </h5>’) % (cookie_name,id)

#E poi lo eliminiamo.ATTENZIONE revoke_session_cookie() elimina il

#cookie associato alla sessione,ma la sessione resta attiva.Se facciamo

#get_session() vediamo che esso torna comunque un identificativo.
manager.revoke_session_cookie()#elimina il cookie di sessione

#Ecco sotto possiamo constatare che nonostante il revoke() la sessione è ancora attiva.

content+=htmltext(‘<h5>get_session(dopo di revoke) —> %s </h5>’) % get_session()

#Qui, se invece il manager non ha un cookie di sessione sul cliente, e la seconda

#volta che passiamo per test_cookie() ,non c’è l’ha dato che se prima

#C’era ,la condizione if l ha cancellato con revoke().

else:#altrimenti crea un cookie di nome ‘nome’ e di value  ‘value’

#Questa sotto crea il cookie di nome ‘nome’ e value ‘valore’
get_request().response.set_cookie(‘nome’,’valore’)

#Ed infatti ci avvisa che il cookie è stato eliminato ma la sessione no

#Attenzione a non confondersi,sebbne sopra creiamo un cookie ,con set_cookie()

#qui sotto ci dice che il cookie è stato eliminato.Certamente potevo esporre meglio

#Per non sbagliare considerate che il rigo qui sotto si riferisce alla condizione else

#riferita all assenza dei cookie,se anche adesso nella condizione esle il cookie viene

#ricreato , questo lo vedremo alla prossima request()
content+=htmltext(u'<p>ATTENZIONE il   cookie  è stato elimi1ato ma le sessione NO! </p>’)

#Questo rigo sotto ci da la possibilità ,nella condizione che non abbiamo cookie di sessione

#di chiamare da un link il metodo pp() che si puo vedere piu sotto

content += htmltext(‘<a href=pp>req</a>’)

#Qui possiamo vedere le coppie  di tuple [(id_sessione,oggetto sessione)]

#ritornate dal metodo items() del manager.

#A dimostrazione che nonostante il cookie è stato eliminato ,il manager continua

#a trovare sessioni.
content += htmltext(‘<h5>lista di sessioni (id,sessione)   –>  %s</h5>’) % manager.items()

return content


def pp(self):

“””

Questo è il metodo richiamato dal link sopra nel codice della condizione else:

che ci serve per creare la sessione dopo che è stato eliminatoil cookie di sessione.

Ricordiamoci inoltre che il metodo set-cookie() appartiene all oggetto response

Infatti lo troviamo nel modulo HTTP_response.py,insieme ad altri metodi

tra cui expire_cookie() per limitarne la scadenza.e.

Mentre i metodi per tornare i cookie appartengono all oggetto request

come il metodo get_cookie().

“””

ss=get_session()
ss.set_user(‘user di sessione’)
return ‘<a href=test_cookie>test_cookie</a>

Dicevamo in altre pagine che comunque quixote mette a disposizione molte altre utilità.

Nel modulo util.py ce ne sono diverse.Ad esempio abbiamo un metodo per creare servizi web atraverso

XML-RPC    (Remote Procedure Calling).

In questo paragrafo farò un esempio di come un file php possa servirsi ,attraverso una procedura remota

di una funzione  scritta in un altro linguaggio.(quixote-python)

Prima 2 parole sui servizi-web e XML-RPC. I web services servono per contribuire all interoperabilità tra

piattaforme e sistemi software di diversa natura.Ad esempio comunicare direttamente tra php e python.

Oggi i services disponibili sono diversi ed evoluti tipo SOAP e REST.

XML-RPC resta uno dei piu collaudati tra i web-services.L interoperabilità viene garantita da un interfaccia comune

per qualsiasi linguaggio.Sappiamo che i linguaggi e le architetture hardware hanno sistemi diversi per rappresentare dati.

Per ovviare a questo si usa un interfaccia comune scritta in XML, formato testuale,che ci permette la comunicazione

tra client e servizio web poichè i dati vengono prima codificati per XML e poi decodificati per il software che serve la richiesta

o ne usufruisce.Diciamo che si usa XML come linguaggio comune,come se un italiano ed un cinese usano l inglese per comunicare.

Inoltre il protocollo di trasporto usato ,http su TCP,permette di evitare  di scrivere regole di comunicazione per i firewall

(che pero potrebbe avere un altra faccia non positiva).

Scriviamo sotto il SERVIZIO-WEB.

Nel file iniziale dell applicazione Quixote ,uno.ptl,andiamo a  scrivere un nuovo metodo:

Importiamo il modulo util di quixote e xmlrpclib da Python

from quixote import util

import xmlrpclib

#Questa sotto è la funzione che mette a disposizione i servizi web , cioè quelle funzioni che saranno

#chiamate dal client  ‘meth’ e gli eventuali parametri ‘params’.Essa viene chiamata da metodo rpcf

#attributo dell oggetto quixote dirc() di tipo Directory().

def funzione(meth, params):

“””

Questa funzione per ‘meth’ ,considera la possibilità che il client possa scegliere 2 diverse

funzioni.La prima è get_time, che non richiede parametri ,e restituisce la data corrente

formattata per xml-rpc.

La seconda ‘test_params’ ,la usiamo per testare i parametri ,quando sono inviati insieme al

servizio richiesto.


“””

if meth == ‘get_time':


# In questa  anche se inviamo parametri essi verranno ignorati
now = time.gmtime(time.time())
return ‘<h5>%s</h5>’ % xmlrpclib.DateTime(now)


elif meth == ‘test_params':


a,b = params
return ‘<h5>come parametri hai immesso i valori %s e %s </h5>’ % (a, b)

# Questo sotto il metodo-url della classe dirc() dell app. quixote.

# E come si vede ritorna  un oggetto xmlrpc che prende come argomenti,un oggetto request

# ‘ get_request() ‘ e la funzione  ‘ funzione’ ,che è quella definita sopra ,che come abbiamo

# visto definisce i servizi RPC veri e propri [ get_time  , test_params ]  , ed i parametri che gli

# si passano (eventualmente ,dato che possiamo anche ometterli ,se chiamiamo get_time).

#Questi nella codifica XML dei dati , rappresentano i  ‘MESSAGES‘  dell ‘ENVELOPE‘ che possiamo

#vedere esplicitati in SOAP ,e cioè dei tag xml che rappresentano i metodi ed i parametri passati

#attraverso le opportune codifiche dell interfaccia comune  tra client-servizio-web in XML..

def rpcf(self):


return util.xmlrpc(get_request(), funzione)

Definiamo adesso il client ,scritto in php ,ma che ricordiamo potrebbe essere scritto in qualsiasi altro

linguaggio.dato che l’ interfaccia xml  di XML-RPC , rende i metodi del servizio-web universalmente

usufruibili.

Il file.php req_xmlrpc.php dalla libreria PEAR PHP

esula da questa guida decrivere il codice php del client sotto,

Comunque non ne è difficile la comprensione.

<?php

require_once “XML/RPC.php”;

$client = new XML_RPC_Client(‘/rpcf’, ‘nome_server’);

$msg = new XML_RPC_Message(‘test_params’, array(new XML_RPC_Value(‘param1′, ‘string’),new XML_RPC_Value(‘param2′, ‘string’)));

$response = ($client->send($msg));

echo XML_RPC_decode($response->value());

?>

Parte8

Leave a Reply

Your email address will not be published.


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>