[Cheyenne] [pgsql] problème db-cache
Laurent25-May-2011/22:07:04+2:00
Pour créer des variables et procédures globales j'utilise un fichier init.r que je charge dans les workers dans httpd.cfg.
Tout naturellement c'est dans ce fichier que j'ai tenté d'utiliser db-cache/define. Mais quand je fais ça les requêtes mises en cache ne marchent pas, il ne trouve pas de cache.
Le seul moyen que j'ai trouvé c'est de mettre directement dbcache/define dans mes pages rsp mais c'est redondant et pas propre. Je n'utilise pas de webapp donc je ne peux pas mettre le code "on session start" ou autre.

A part ça la cachage marche super bien, mes pages sont générées 4 fois plus vite quand ça fonctionne.

Cher Doc, un petit fix??
DocKimbel25-May-2011/23:58:35+2:00
Si tu n'utilises pas les webapps, la définition des URLs d'accès aux bases doit être faite impérativement dans la section "globals" du fichier config, sinon le moteur RSP ne les trouvera pas.

Je vais regarder çà en détail dimanche après le Cht'i RUG.
Laurent28-May-2011/15:00:29+2:00
Oui c'est bien ce que je fais:
globals [
		
	bind SSI to [.shtml .shtm]
	
	bind-extern CGI to [.cgi]
	bind-extern RSP to [.j .rsp .r]

	
	databases [
			db	pgsql://toto:titi@localhost/monsite
	]

	worker-libs [
		%libs/pgsql-protocol-091.r
		%libs/tools.r
		%/home/monsite/init.r
;		on-quit [
;			%/libs/close-all.r
;		]
	]

	block [
		"w00tw00t"				;-- block DFind scanner
		"msgimport"				;-- block msg import interface attacks
		" http://"				;-- block proxy relay attempts
		" GET "					;-- block white space base buffer overflow attacks
		"php"					;-- block attacks targeting PHP scripts
		ip-host					;-- block web scanners using IP instead of a valid domain in Host header
	]
	
	allow-ip-banning 0:01:00	;-- optionally ban all blocked IP for the time passed as argument
								;-- (1 minute by default if no argument)

]

default [
	root-dir %/home/monsite/www/
	
	default [%index.rsp %index.html]

	locales-dir %locales/

	debug
	
	on-status-code [
		404	  "/custom404.html"
	]
	
	timeout	240:00:00

]


Bon Cht'i RUG , dommage que je ne puisse pas être présent.
Laurent7-Jun-2011/15:09:40+2:00
UP du soir, espoir...
DocKimbel8-Jun-2011/15:49:36+2:00
Pour créer des variables et procédures globales j'utilise un fichier init.r que je charge dans les workers dans httpd.cfg. Tout naturellement c'est dans ce fichier que j'ai tenté d'utiliser db-cache/define. Mais quand je fais ça les requêtes mises en cache ne marchent pas, il ne trouve pas de cache.

L'option WORKER-LIBS charge des librairies de code au démarrage d'un "worker process", donc bien avant que le moteur RSP soit chargé, donc initialiser le cache des requêtes SQL du moteur RSP à ce niveau a toutes les chances de ne pas marcher.

Une option possible afin d'éviter de le faire à chaque chargement de page RSP, serait d'utiliser une cache mémoire du type: 
unless value? 'db-cache-init [
    db-cache-init: yes
    db-cache/define [...]
]


Ce bout de code devrait être inclu en début de tous les scripts RSP utilisant le cache, celui-ci ne sera chargé qu'une fois par "worker process". Mais attention, utiliser db-cache sans la protection d'une webapp signifie que la moindre erreur de programmation dans tes scripts RSP pourrait exposer des données privées à tous ceux qui peuvent accéder à ces pages RSP.

La bonne solution actuellement pour utiliser ce genre de cache est de passer une webapp. Y'a-t'il une raison qui t'en empêche ?

PS: je ne t'avais pas oublié, mais je suis très pris ces derniers jours sur la finition de Red/System...
Laurent10-Jun-2011/16:50:15+2:00
Oui c'est ce que je fais déjà (le coup du "unless value etc).
Au tout début de mon projet j'avais testé les webapp qui facilitent pas mal de choses mais qui me posaient des problèmes quand certaines pages de mon site devaient être d'accès protégé par login/cookie et pas d'autres. Je ne me rappelle plus exactement, je me replongerai dedans et je te dirai. C'est vraiment dommage car le concept de webapp est très intéressant en effet.

Mais que veux-tu dire par " la moindre erreur de programmation dans tes scripts RSP pourrait exposer des données privées à tous ceux qui peuvent accéder à ces pages RSP" ?? Une erreur de script RSP peut faire s'afficher le code même en mode debug/off ?? Je voudrais bien un exemple...

PS: Ne t'inquiètes pas, pas de souci niveau temps de réponse dans le forum, prends tout ton temps pour nous faire un beau langage Red, c'est le plus important En plus ça fait deux mois que suite à mon déménagement je n'ai pas l'internet. Donc je consulte le site assez irrégulièrement, dans les bars wifi. Merci Free/FT !
Laurent10-Jun-2011/17:17:08+2:00
Et oui en relisant le wiki webapp je me rappelle que ce qui me posait problème avec les c'est qu'une partie de mon site doit être accessible en se loguant, mais aussi qu'une partie du site doit être accessible sans se loguer (c'est un site web grand public). A l'époque je n'avais pas trouvé comment faire en passant par les webapps qui apparemment font du tout ou rien niveau gestion des sessions pour les scripts RSP.

S'il y a une façon de faire que je n'ai pas vue ou un fix je suis preneur!
trigram10-Jun-2011/17:58:03+2:00
Normalement, les pages/scripts/élements images et autres qui doivent être publiques même sans être connecté doivent se trouver dans %public

Par exemple, dans l'exemple livré avec Cheyenne, tu as un %time.rsp qui se trouve dans %www/testapp/public
DocKimbel10-Jun-2011/19:21:45+2:00
Mais que veux-tu dire par " la moindre erreur de programmation dans tes scripts RSP pourrait exposer des données privées à tous ceux qui peuvent accéder à ces pages RSP" ?? Une erreur de script RSP peut faire s'afficher le code même en mode debug/off ?? Je voudrais bien un exemple...

Non non, je ne parlais que des données uniquement et pas du code. Les webapps garantissent un niveau d'isolation du code supérieur à de simples scripts RSP, du coup, les risques d'exposition de données d'un utilisateur à un autre dues à une erreur de programmation sont un peu plus élevés dans le cas de scripts RSP simples.

Pour gérer une partie en public et l'autre en privée, tu peux:
- mettre la partie publique dans /webapp/public/
- mettre la partie publique à un niveau supérieur: /* => public, /app/* => privé
- tout mettre dans la même webapp et au lieu d'utiliser l'option AUTH, gérer sa propre variable de session pour marquer les users authentifiés et utiliser un filtre dans 'on-page-start pour protéger les pages privées des users non-authentifiés.
Laurent14-Jun-2011/16:10:17+2:00
Je mettais mes libs etc dans un répértoire supérieur au repertoire root Cheyenne. Est-ce que le dossier /private est encore plus sûr que ça? De toute façon si il faut utiliser les webapps pour utiliser les requêtes en cache alors je vais utiliser les webapps

Pour résumer: mes pages publiques concentrent le traffic et doivent donc absolument utiliser des requêtes en cache. Donc elles doivent faire partie de la webapp. Donc j'ai défini le repertoire root cheyenne /www comme étant egalement le répertoire webapp, c'est à dire un virtualdirectory webapp = "/" .
Comme je veux éviter de me trimbaler le préfixe "/public" devant toutes mes url de pages publiques (c'est laid) j'ai du me passer de la directive "auth" et gérer moi même les sessions, heureusement ça n'est pas trop génant.


Quatres choses à signaler:

1) les variables déclarées dans le host ("default" en l'occurence) ne sont pas prises en compte dans le bloc de config webapp et sont a remettre dedans. Par exemple "locales-dir". Est-ce normal?

2) Un autre truc qui me gène c'est que bien que je n'utilise pas "auth" les sessions sont automatiquement actives et contiennent la variable booléenne "session/content/login?" qui ne me sert absolument à rien. En effet j'utilise une variable user-login qui comme son nom l'indique contient le pseudo de l'utilisateur ou alors none si il n'est pas logué.
Est-ce que la variable spéciale "session/content/login?" qui si j'ai bien lu sert pour les pages où on doit être identifié est egalement nécessaire pour la protection du dossier private? Si ce n'est pas le cas ça serait bien de ne pas démarrer automatiquement les sessions ni d'ajouter cette variable quand on utilise pas "auth". Je sais je chipote mais bon ce genre de truc c'est agaçant quand on gère les sessions...

3) Un bug qui m'a rendu dingue: quand le debug est "on" alors dans "on-page-start" mes variables de session ne sont plus reconnues (ex: Script Error : Invalid path value: user-login Near   [__emit session/content/user-login __txt 480 5] ), plus possible de faire de redirections, et plein de choses très bizarres. Tout ça uniquement dans "on-page-start", la page elle même marchant bien. J'ai tout essayer et tout redemarrer 36000 fois avant de m'appercevoir que ça venait du debug. Ainsi dans mon "on-page-start" je suis obligé de mettre un debug/off au début et un debug/on à la fin. Ca serait super d'avoir un petit fix là dessus.

4) A part le ces trois points ci-dessus en effet l'utilisation des webapps se révèle bien pratique. Désormais je mets mes includes de header et footer uniquement dans "on-page-start" et "on-page-end", c'est moins redondant. Et surtout les requètes mises en cache marchent bien.²
Laurent14-Jun-2011/16:13:35+2:00
(tout essayé tout redemarré ça m'énerve ce genre de fautes)
trigram16-Jun-2011/16:01:19+2:00
Merci Laurent pour tes retours.

J'ai aussi des gros soucis avec le point n° 3.

DocKimbel !!! We need YOU !
DocKimbel18-Jun-2011/18:11:34+2:00
@Laurent

1) Le terme "variable" est impropre dans ce contexte. Ce sont des mot-clés ou des options de configuration. Une webapp définit son propre espace de travail qui peut être différent de l'espace racine. Elle n'hérite donc pas des options de configuration de la racine. Il devrait être possible je pense de changer cette règle et de pouvoir hériter de quelques options comme: root-dir, default, on-status-code, etc... Je vais regarder çà dans ma prochaine session de travail sur Cheyenne.

2) AUTH gère la protection des ressources contre les accès non-authentifiés en lisant la valeur de session/content/login?, mais n'a aucune influence sur la gestion de la session. La protection du dossier %private/ est totale, il n'est JAMAIS accessible par les utilisateurs, AUTH ou pas, c'est une propriété de toutes les webapps, de même que la gestion automatique des sessions. Il faut bien distinguer les sessions et le fait d'être authentifié, c'est deux choses différentes. Une session permet de suivre une utilisateur anonyme donné et de lui attribuer un contexte dédié en mémoire pour y stocker des données. Une session peut être authentifiée ou pas. On peut mettre en place ses propres règles d'authentification et de séparation des ressources accessibles à tous et celles qui sont restreintes. AUTH simplifie cette gestion en protégeant par défaut, l'ensemble de la webapp, tant que l'authentification n'est pas faite. Toutes les webapps n'ont pas forcément besoin de gérer une authentification.

Si ce n'est pas le cas ça serait bien de ne pas démarrer automatiquement les sessions ni d'ajouter cette variable quand on utilise pas "auth". Je sais je chipote mais bon ce genre de truc c'est agaçant quand on gère les sessions...

Je ne comprends pas bien, tu gères manuellement les sessions ? Si c'est le cas, il ne faut pas utiliser une webapp, ce n'est pas compatible.

3) Je n'arrive pas à reproduire le problème dans 'on-page-start. Si je définis une variable de session dans 'on-session-start et que j'y accède dans 'on-page-start en mode debug, ça marche sans pb. Peux-tu me fournir un exemple de code provoquant l'erreur ?
Laurent21-Jun-2011/19:16:10+2:00
@DocKimbel

1) ok je suivrai ça de près.

2) je conçois bien la différence entre une SESSION identifiée par son id unique pour pouvoir différencier les différents utilisateurs dans un contexte multi-utilisateurs, session qui peut être authentifiée ou pas, et l'AUTHENTIFICATION elle même qui est géréee pat AUTH ou bien par moi.
Avant d'utiliser les webapps je gérais moi même les SESSIONS (créations etc) et l'AUTENTIFICATION (j'utilise une variable de session user-login qui est à "none" quand la session est non identifiée).
En passant aux webapps (apparement je n'ai pas d'autre choix si je veux utiliser dbcache) j'ai pu constater que, même SANS utiliser l'option de configuration AUTH dans ma config webapps, les SESSIONS étaient alors automatiquement ouvertes avec la fameuse variable "login" (en plus de "id"), ce qui m'a obligé a réécrire mon code de gestion des SESSIONS en laisssant la main la dessus au webapps. Je me suis fait a cette idée des sessions créées automatiquement par les webapps. Pas de souci, je ne m'occupe plus désormais que de l'AUTHENTIFICATION.
Simplement ce qui me gène c'est que cette variable "login" créée par défaut est la pour gérer l'AUTHENTIFICATION (tu m'arrêtes si je me trompe) par AUTH (directive bien nommée). Donc je me retrouve avec cette variable d'AUTHENTIFICATION inutile qui est en double emploi avec ma variable "user-login". D'où ma petite remarque pour signaler que même sans utiliser AUTH les webapps interfèrent quand même avec le processus d'AUTHENTIFICATION en cela qu'elles créent cette variable "login" dont on ne peut pas se débarrasser.

3) Je n'aime pas trop publier sur le net mon code qui sert en grande partie a l'authentification mais bon si c'est pour la bonne cause alors voilà mon fichier app-init.r:

J'utilise des variables globales "contextualisées" monsite/menu et monsite/public-pages qui sont définies une fois pour toutes dans init.r (ce sont des series de mots (noms de pages) et de leurs valeurs associées)

Pour l'instant j'utilise un breadcrumb simplifié qui à besoin des variables "page" (page courante) et "menu" (menu racine de la page). Ce breadcrumb est généré dans le header appelé par un include.

REBOL [
	File: %app-init.r
	Purpose: "Events definition for webapp /app"
]
on-application-start: does [
	;--- add here your library / modules loading
	do %private/init.r
	
]
on-application-end: does [
	;--- add here your library / modules proper closing
]
on-database-init: does [
	;--- add here instance specific init code
	do %private/db-cache.r
]
on-session-start: does [
	;--- add here your per session init code
]
on-session-end: does [
	;--- add here your per session closing/cleanup code
]
on-page-start: does [
	;--- add here processing code run before a RSP page is evaluated
	
	debug/off
	
	page: to word! replace copy (last parse/all request/parsed/file "/") ".rsp" ""
	menu: to word! any [(select request/content 'menu) page]
	if not find monsite/menu menu [menu: 'index]
	
	if not find monsite/public-pages page [
		if not all [session/active? session/exists? 'user-login session/content/user-login] [
			response/redirect rejoin ["/login.rsp?menu=" menu]
		]
	]
	
	debug/on
	
	if request/parsed/path <> "/tests/" [include %private/includes/header.rsp] 
	
]
on-page-end: does [
	;--- add here processing code run after a RSP page is evaluated
	if request/parsed/path <> "/tests/" [include %private/includes/footer.rsp]
]

Login required to Post.


Powered by RebelBB and REBOL 2.7.8.4.2