spip-contrib-extensions
/
menu_langues_liens
99
0
Fork 0
Code Issues 5 Pull Requests 1 Releases Wiki Activity
Labels Milestones

feat: nouvelle option de config permettant de changer en base la langue de la personne connectée, en plus du cookie. #7

Open
tcharlss wants to merge 1 commits from dev/issue_2_config_langue_sql into master
Conversation 1 Commits 1 Files Changed 4
tcharlss commented 5 months ago
Owner

L'objectif indirect c'est que les notifs partent dans la bonne langue, celle choisie par la personne en front.

L'action converser du core ne permet pour l'instant pas cela, cf. spip/spip#4912
On la surcharge donc en lui faisant prendre en compte un nouveau param var_lang_sql (POST ou GET).
Celui-ci fait la même chose que var_lang, mais en plus ça met à jour en base donc.
Par défaut l'action fait toujours la même chose, c'est une option supplémentaire.

Dans la config l'option est au tout début, car ça modifie le comportement du menu, c'est important.

Ref: #2

La nouvelle option de config.
Edit : j'ai regroupé ça avec la redirection dans un fieldset « comportement » plutôt que d'en ajouter un autre. Et mis au début.

L'objectif indirect c'est que les notifs partent dans la bonne langue, celle choisie par la personne en front. L'action converser du core ne permet pour l'instant pas cela, cf. https://git.spip.net/spip/spip/issues/4912 On la surcharge donc en lui faisant prendre en compte un nouveau param `var_lang_sql` (POST ou GET). Celui-ci fait la même chose que `var_lang`, mais en plus ça met à jour en base donc. Par défaut l'action fait toujours la même chose, c'est une option supplémentaire. Dans la config l'option est au tout début, car ça modifie le comportement du menu, c'est important. Ref: #2 La nouvelle option de config. Edit : j'ai regroupé ça avec la redirection dans un fieldset « comportement » plutôt que d'en ajouter un autre. Et mis au début. ![](https://git.spip.net/attachments/de4cdcb0-3d0a-4a26-9fc6-0a1000ebf5f9)
cfg_mll_bis.png
41 KiB
tcharlss added 1 commit 5 months ago
f32eacef74 feat: nouvelle option de config permettant de changer en base la langue perso de la personne connectée, en plus du cookie.
tcharlss changed title from feat: nouvelle option de config permettant de changer en base la langue perso de la personne connectée, en plus du cookie. to feat: nouvelle option de config permettant de changer en base la langue de la personne connectée, en plus du cookie. 5 months ago
tcharlss commented 5 months ago
Poster
Owner

Eeeeeet qui c'est qui oublie de mettre à jour son dépôt avant de créer sa branche ? C'est bibi

Eeeeeet qui c'est qui oublie de mettre à jour son dépôt avant de créer sa branche ? C'est bibi
tcharlss force-pushed dev/issue_2_config_langue_sql from f32eacef74 to 7cbe1ef4c5 5 months ago
rastapopoulos requested changes 5 months ago
action/converser.php
if ($lang = _request('var_lang')) {
action_converser_post($lang);
// Màj cookie général + langue sql
} elseif ($lang = _request('var_lang_sql')) {
rastapopoulos commented 5 months ago
Owner

Je ne pense pas que cette action doit introduire une nouvelle manière de passe la langue, d'autant plus si ça a vocation à devenir la PR pour le core. Les deux manières d'envoyer la langue distinguent si c'est la langue pour le public, ou pour le privé, et c'est important car c'est pas le même cookie (et on peut avoir deux langues différentes comme je le disais dans le ticket, par ex anglais en public et russe en privé car ya plus de langues dispos en privé), mais donc c'est sans rapport avec le fait de stocker en base/session ou pas.

Il y a déjà un argument possible prévu pour dire qu'on veut garder en mémoire dans l'auteur, c'est le "arg" s'il est présent, qui active le update_session true, qui enregistre en base spip_auteurs (et donc en session de l'auteur, les deux sont liés).

C'est donc cette variable là qu'il faut utiliser, qui existe déjà, et uniquement cela. Il ne faut donc pas garder les if du passé tel quel (par ex le premier qui fait directement et uniquement action_converser_post($lang)), mais mutualiser des choses entre public et privé, et si ya le update_session true, alors garder en base+session.

Je ne pense pas que cette action doit introduire une nouvelle manière de passe la langue, d'autant plus si ça a vocation à devenir la PR pour le core. Les deux manières d'envoyer la langue distinguent si c'est la langue pour le public, ou pour le privé, et c'est important car c'est pas le même cookie (et on peut avoir deux langues différentes comme je le disais dans le ticket, par ex anglais en public et russe en privé car ya plus de langues dispos en privé), mais donc c'est sans rapport avec le fait de stocker en base/session ou pas. Il y a *déjà* un argument possible prévu pour dire qu'on veut garder en mémoire *dans l'auteur*, c'est le "arg" s'il est présent, qui active le update_session true, qui enregistre en base spip_auteurs (et donc en session de l'auteur, les deux sont liés). C'est donc cette variable là qu'il faut utiliser, qui existe déjà, et uniquement cela. Il ne faut donc pas garder les if du passé tel quel (par ex le premier qui fait *directement et uniquement* `action_converser_post($lang)`), mais mutualiser des choses entre public et privé, et si ya le update_session true, alors garder en base+session.
tcharlss commented 5 months ago
Poster
Owner

Il y a déjà un argument possible prévu pour dire qu'on veut garder en mémoire dans l'auteur, c'est le "arg" s'il est présent, qui active le update_session true, qui enregistre en base spip_auteurs (et donc en session de l'auteur, les deux sont liés).

Oui j'y ai pensé mais c'est pas si simple.

Quand t'as le arg, alors ça sécurise l'action, et donc on peut plus l'utiliser de façon anonyme.

if (_request('arg') and spip_connect()) {
	$securiser_action = charger_fonction('securiser_action', 'inc');
	$securiser_action();
	$update_session = true;
}

Pour l'instant ça a pas vraiment vocation à devenir la PR telle quelle dans le core, y a encore des trucs en discussion dans le ticket.

Ça pourrait même ne pas être une surcharge de l'action converser, mais une autre action spéciale pour le plugin mll_converser ou autre, en attendant que ça soit faisable dans le core.

> Il y a déjà un argument possible prévu pour dire qu'on veut garder en mémoire dans l'auteur, c'est le "arg" s'il est présent, qui active le update_session true, qui enregistre en base spip_auteurs (et donc en session de l'auteur, les deux sont liés). Oui j'y ai pensé mais c'est pas si simple. Quand t'as le arg, alors ça sécurise l'action, et donc on peut plus l'utiliser de façon anonyme. ```php if (_request('arg') and spip_connect()) { $securiser_action = charger_fonction('securiser_action', 'inc'); $securiser_action(); $update_session = true; } ``` Pour l'instant ça a pas vraiment vocation à devenir la PR telle quelle dans le core, y a encore des trucs en discussion dans le ticket. Ça pourrait même ne *pas* être une surcharge de l'action `converser`, mais une autre action spéciale pour le plugin `mll_converser` ou autre, en attendant que ça soit faisable dans le core.
rastapopoulos commented 5 months ago
Owner

Oui j'ai bien vu mais justement, soit on considère que pour avoir update_session (et donc sql ça va ensemble) il faut toujours sécuriser, soit jamais, mais pas une fois oui une fois non, il me semble.

Et donc dans le squelette faudrait un truc du genre par défaut, comme maintenant, et SI ya l'option cochée, faut que lien soit propre à l'utilisateur pour pouvoir faire une action sécu.
(attention au cache, donc soit #SESSION + #URL_ACTION_AUTEUR, soit le mieux serait peut-être d'utiliser du <?php c'est un cas légitime)

Ou bien on dit qu'on sécurise jamais l'action au sens de "qui a cliqué" (ce qui est le cas 99% du temps pour juste changer le cookie public), mais que dedans ya bien qui est l'auteur réellement connecté, et que ça suffit car c'est une modif fort minime ne concernant que "lang", donc on peut normalement pas avoir un truc grave en changer son SQL juste pour ça. (mais si on peut avoir tout sécurisé c'est encore mieux)

Oui j'ai bien vu mais justement, soit on considère que pour avoir update_session (et donc sql ça va ensemble) il faut toujours sécuriser, soit jamais, mais pas une fois oui une fois non, il me semble. Et donc dans le squelette faudrait un truc du genre par défaut, comme maintenant, et SI ya l'option cochée, faut que lien soit propre à l'utilisateur pour pouvoir faire une action sécu. (attention au cache, donc soit #SESSION + #URL_ACTION_AUTEUR, soit le mieux serait peut-être d'utiliser du `<?php` c'est un cas légitime) Ou bien on dit qu'on sécurise jamais l'action au sens de "qui a cliqué" (ce qui est le cas 99% du temps pour juste changer le cookie public), mais que dedans ya bien qui est l'auteur réellement connecté, et que ça suffit car c'est une modif fort minime ne concernant que "lang", donc on peut normalement pas avoir un truc grave en changer son SQL juste pour ça. (mais si on peut avoir tout sécurisé c'est encore mieux)
tcharlss commented 5 months ago
Poster
Owner

Ouais je suppose qu'on peut faire ces tests dans le squelette (il va avoir une belle gueule à la fin ^^).

Bon essayons de résumer le mode d'emploi de cette action au final :

  • Dans tous les cas, on indique la langue dans une param en POST ou GET :
    • OU var_lang pour poser le cookie général
    • OU var_lang_ecrire pour poser le cookie général + le cookie du privé
  • Et en plus, si on appelle la fonction de façon sécurisée OU qu'on utilise var_lang_ecrire, alors ça fait la màj sql ET la màj de la session (pose d'un autre cookie).

On est d'accord ?
La seule différence avec l'actuel serait de faire la màj de session également en cas d'appel sécurisé, plus uniquement en présence de var_lang_ecrire.

Qui a dit cryptique ?

Ouais je suppose qu'on peut faire ces tests dans le squelette (il va avoir une belle gueule à la fin ^^). Bon essayons de résumer le mode d'emploi de cette action au final : * Dans tous les cas, on indique la langue dans une param en POST ou GET : * OU `var_lang` pour poser le cookie général * OU `var_lang_ecrire` pour poser le cookie général + le cookie du privé * Et *en plus*, si on appelle la fonction de façon sécurisée OU qu'on utilise `var_lang_ecrire`, alors ça fait la màj sql ET la màj de la session (pose d'un autre cookie). On est d'accord ? La seule différence avec l'actuel serait de faire la màj de session également en cas d'appel sécurisé, plus uniquement en présence de `var_lang_ecrire`. Qui a dit cryptique ?
rastapopoulos commented 5 months ago
Owner

Je n'ai pas compris ton deuxième point : dans l'état actuellement c'est pas un OU, mais bien ET, quand on met var_lang_ecrire seul, ça n'active pas la màj du SQL, si c'est ya var_lang_ecrire ET qu'on a du sécurisé ET que arg est rempli !

Le mode d'emploi voulu je le résumerais plutôt comme ça :

  1. S'il c'est sécurisé ET que c'est demandé par "arg", on active le mode SQL/session
  2. Suivant le var_truc envoyé, on récupère la langue voulue
  3. Si point 1, on update la session (quelque soit d'où vient la langue !)
  4. On appelle action_converser_post() avec la bonne langue et les bons params (dont sql ou pas suivant point 1)

C'est plus clair listé comme ça ? :)

Je n'ai pas compris ton deuxième point : dans l'état actuellement c'est pas un OU, mais bien ET, quand on met var_lang_ecrire seul, ça n'active pas la màj du SQL, si c'est ya var_lang_ecrire ET qu'on a du sécurisé ET que arg est rempli ! Le mode d'emploi *voulu* je le résumerais plutôt comme ça : 1) S'il c'est sécurisé ET que c'est demandé par "arg", on active le mode SQL/session 2) Suivant le var_truc envoyé, on récupère la langue voulue 3) Si point 1, on update la session (quelque soit d'où vient la langue !) 4) On appelle action_converser_post() avec la bonne langue et les bons params (dont sql ou pas suivant point 1) C'est plus clair listé comme ça ? :)

Reviewers

rastapopoulos requested changes 5 months ago
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
Sign in to join this conversation.
Reviewers
Request review
No reviewers
rastapopoulos
Labels
Apply labels
Clear labels
No items
No Label
Milestone
Set milestone
Clear milestone
No items
No Milestone
Assignees
Assign users
Clear assignees
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Write Preview
Loading…
Cancel
Save
There is no content yet.
Delete Branch 'dev/issue_2_config_langue_sql'

Deleting a branch is permanent. It CANNOT be undone. Continue?

No
Yes