Description

FrameWork

FW e' un web application content realizzato con lo scopo di rendere facile rapido ed intuitivo lo sviluppo di applicazioni php scritte per essere fruite da utenti anonimi o autenticati su internet quanto in ambienti intra/extranet.

Concetti di base

FW e' totalmente decentrato.

La struttura di base contiene l'unico punto d'avvio (index.php), la strutture di base e le librerie comuni.

Questo approccio ha lo scopo di rendere questa applicazione piu' flessibile piu facilmente modificabile e di togliere certezze a chi attacca in quanto non si puo' a priori essere sicuri di quale codice e' usato.

E' inoltre possibile avere parti del codice in competizione tra loro in modo da poter avere sempre il meglio in ogni settore.

E' pensato soppratutto per tutti coloro che personalizzano molto il loro codice.

In questo senso si apre di fatto una piattaforma nuova piu semplice e leggera per realizzare siti web anche molto diversi tra loro.

Una sorta di dos del web ;-)

Tutto il codice pur trattandosi di codice php e' fortemente limitato e si cerca nel limite del possibile di usare codice xHTML e Javascript.

Il tema utilizza solo un foglio di stile css che usa in modo estensivo le classi e la cartella della grafica detta images.

La localizzazione e' anch'essa decentrata nelle applicazioni e nei blocchi.

La struttura e' invece contenuta in blocks/structure.inc che provvede al caricamento dei blocchi e delle applicazioni

E' quindi possibile cambiare la forma del sito senza cambiare il tema e viceversa.

La cartella datas contiene l'unico posto dove framework puo' scrivere e conservare informazioni.

I dati riservati vanno nella security box (sb).

Una sotto-sotto cartella generata automaticamente da un'apposita funzione che ha il compito di nascondere l'accesso ai dati da remoto.

Non dovrebbe essere possibile visualizzare in nessun modo il nome di questa directory che viene passato alle funzioni che ne hanno bisogno dalla funzione che lo ha generato.

Si tratta di un modo importante per nascondere alla vista di male intenzionati dei dati sensibili e al tempo stesso concedere un po' polimorfia al codice stesso di framework.

Naturalmente esistono dati che non conviene mettere in cassaforte o che non e' possibile nasconderne la collocazione (ad esempio i file dell'applicazione download).

In questo caso saranno stoccati semplicemete in datas fuori da sb.

Le sotto pagine centrali sono dette applications (quelle che altrove sono section per intenderci) ed il menu che le lancia e' un blocco come gli altri.

I blocchi hanno 4 cartelle per collocarli top,left,right,bottom.

Fa da se che il titolo e il footer sono blocchi.

Blocchi e Applications possono essere indifferemntemente cartelle o semplici file.

I dati la grafica e la localizzazione devono accompagnare il blocco o l'applicazione quindi se sono necessari verranno ospitati nella cartella del blocco/applicazione.

Per nascondere un blocco applicazione e' sufficente far precedere il nome dal carattere sottolineato (_).

I dati invece vengono conservati in datas.

Per il sort si usa il solito sistema del numero che precede il nome seguito da un _.

Ovviamente non e' possibile usare spazi nel nome applicazione/blocco.

Il numero ovviamente non viene usato nel generare la cartella in datas e ovviamente la creazione della catrtella dati e' a carico del blocco o del'applicazione usando pero funzioni fornite dalle librerie standard.

Blocchi e applicazioni hanno anche in carico la creazione della propria cornice e della propria amministrazione.

In pratica FrameWork passa la parola al blocco/applicazione e mette a disposizione le proprie funzioni.

Sara' poi quest'ultima a svolgere il resto del lavoro avvalendosi del codice a disposizione nelle librerie.

E' importante notare che questo approccio permette anche la rinuncia all'uso di quest'ultime rendendo almeno in teoria piu facile adattare software gia scritto a questa piattaforma.

Autenticazione utenti e forum sono tutte applicazioni esterne al nocciolo principale e potranno esistere soluzioni piu' o meno evolute come alternative.

La configurazione generale (lingua, ora, path, ecc.) viene impostata attraverso il file config.inc

Da notare che questo file non esporta variabili ma funzioni che restitutiscono il valore richiesto.

Questo approccio consente di avere la restituzione di dati in maniera piu intelligente.

Faccio un esempio:

Le funzioni dell'amministrazione sono  locate nella libreria libAdmin.inc. e c'e' a disposizione il blocco admin per l'inserimento password. E' stato poi creata l'applicazione admin per la configurazione delle preferenze dell'amministratore oltre che altrnativa al blocco di autenticazione.

FrameWork e' molto tollerante all'uso del carattere _ per nascondere l'applicazione. E' infatti in grado di trovare comunque l'applicazione anche se viene invocata con il nome non nascosto.

L'amministarizione non usa un utente particolare (anzi non usa proprio nessun utente) e non usa nessun cookie solo un utente per volta puo' amministrare il sito e per poter amministrare deve prima di tutto avviare la propria sessione immetendo la password attraverso l'apposito blocco.

A questo punto il sistema registra l'ip dell'amministratore e non richiede piu' la password.

Riconosce inoltre l'amministratore ed espone i servizi di amministrazione che altrimenti non sono accessibili.

Quando l'amministratore ha terminato il lavoro è tenuto a scollegarsi usando il comando stopsession.

Questo tipo di autenticazione mi sembra piu' sicura di una generica basata su cookie.

E' possibile comunque implementarne una basata su cookie semplicemente sostituendo la libreria libAdmin.

L'editor e' un accessorio dell'amministrazione ma come logico in questo sistema non ne fa parte ma e' un applicazione come le altre.

Si tratta di un applicazione nascosta in quanto non puo' funzionare se non riceve il nome del file da editare.

Puo' anche funzionare senza i privilegi di amministrazione in quanto svolge solo i compiti di editazione e non il salvataggio.

E' evidente che questa parte e' cruciale per la sicurezza. In frameWork l'editor puo' caricare il file e modificarlo ma per il salvataggio si aspetta che l'applicazione che ha richiesto il suo intervento sia in grado di ricevere le modifiche e sia in grado di salvarle.

Ogni suggerimento di sicurezza in questa parte e' il benvenuto e anche
un testing forzato e sistematico deve essere svolto con cura per prevenire possibili buchi.

_editor.inc funziona sia da solo sia con il supporto presente nella cartella extras di FCKeditor che nel caso fosse presente sara' automaticamente usato.

La cartella extras e' preposta a contenere tutto il software aggiuntivo esterno come CFKeditor oppure (come esempio) txtshout.

Le librerie sono invece presenti in una cartella chiamata libs e vengono caricate automaticamente come i blocchi.

Il codice java script viene incluso attraverso un comando include e risiede in file separato.


Questo fa si che il caricamento risulti decentrato e dovrebbe alleggerire il carico del server web.

Pur non essendo parte del core FrameWork dispone di un ottimo supporto utenti e gruppi formato da due librerie separate, un blocco login e un applicazione (reguser) per il login e l'amministrazione utenti e gruppi.

E' pensato per poter funzionare anche senza il supporto gruppi.

L'autenticazione degli utenti avviene tramite l'uso di cookie e le password sono conservate in sb e criptate con chiave md5.

I gruppi invece sono liste conservate in sb e amministrate da admin.

La creazione dei gruppi e' a carico delle applicazioni che ne fanno uso mentre l'iscrizione hai gruppi degli utenti deve essere fatta dall'aministratore tramite apposita interfaccia gia implementata in reguser. Gli utenti che appartengono al gruppo dell'applicazione hanno privilegi maggiori rispetto agli utenti normali. tutte queste funzioni sono da implementare nel codice dei blocchi funzioni.

Al momento l'unica applicazione che fa un uso peraltro limitato dei gruppi e' description ma presto ne seguiranno parecchie altre.

Non e' al mometo previsto nessun tool grafico per la rimozione dei gruppi pur essendo nella libreria disponibile la funzione preposta ma e' comunque possibile eliminare tutti gli utenti.

Per convenzione ogni libreria possiede una costante che comunica al sistema se essa e' presente. Le applicazioni possono in questo modo sapere se e' presente la libreria ed evitare dieseguire codice non supportato. La lettura del codice penso sia molto piu chiara di questa spiegazione.

Sono state create anche delle convenzioni per la trasmissione dei dati da parte delle librerie. Se queste devono essere trasmesse tramite il metodo get o il metodo post nella libreria e' presente un albero a switch preposto a ricevere i parametri e a chiamare la funzione. Il tutto alla ricerca del massimo controllo sui dati immessi dagli utenti.

il codice presente e' da considerarsi un codice esplorativo per verificare la effettiva fattibilita' di questo tool

ringrazio tutto il team di viluppo e sono naturalmete  a disposizione tramite mail per ogni ulteriore chiarimento
                                                                             Viola Roberto   __vroby__ (__vroby__@libero.it)