Système de MP, 2 questions

403 means that you can't access the resource regardless of who you are authenticated as.

403 quand on accède à une ressource sans les autorisations nécessaires.

CQFD, merci.

Vous voyez vous êtes d'accord avec moi maintenant. Donc si on a pas l'autorisation d'afficher une conversation c'est une 403.

Tu sais que "regardless of who you are", ça veut dire "qui que tu sois" ? Donc que ce que j'ai dit ici :

Ce que tu essayes de démentir depuis le début… "CQFD" comme tu dis.

ces deux termes sont, dans ce contexte très précis, les mêmes.

C'est faux

une 403, le serveur n'écoute même pas et ne levera pas le petit doigt pour voir s'il peut accéder à ta requête.

C'est faux. Si le serveur n'écoute pas comment veux-tu qu'il sache si tu as l'autorisation ?

cette RFC est sujette diverses interprétations

C'est faux. Non pour le coup c'est vrai, sinon on en serait pas là.

une 401 quand le gus n'a juste pas les droits nécessaires

C'est faux. Une 401 survient quand une authentification HTTP est nécessaire et que des identifiants n'ont pas été fournis ou sont faux. Ce n'est pas le cas ici et tu ne cesses de vouloir une 401. Donc ben c'est faux.

la 403 en "interdit". C'est à dire, qui que tu sois, tu n'auras pas accès à la ressource. C'est tout

C'est faux. C'est interdit uniquement si tu n'as pas l'autorisation, ce que tu n'as jamais précisé.

Oui juste jeter une AccessDeniedHttpException suffit amplement à ce qu'il veut faire (même si bon, ce serait plutôt une 401 dans ce cas mébonbref).

A noter que la classe Controller du FrameworkBundle met à disposition une méthode createAccessDeniedException qui retourne une instance de Symfony\Component\Security\Core\Exception\AccessDeniedException qu'il ne reste qu'à lever. Et c'est bien une 403 qu'il faut retourner ; si la requête a passé les firewalls de Symfony c'est que l'utilisateur est authentifié.

Oui, c'est bien une 403, pas de doute possible là-dessus. C'est pour ça que j'ai en premier lieu $this->denyAccessUnlessGranted('ROLE_USER'). Si ça passe, l'utilisateur est bien connecté; s'il n'est pas connecté alors cette ligne a pour effet de rediriger vers le formulaire de login fourni par FOSUserBundle. Ça ça fonctionne nickel.

Je note l'existance de la méthode, merci! J'étais déjà en train de fouiller dans le dossier vendor pour savoir où était cette #*@%$§£ÿ de classe AccessDeniedHttpException qui n'est bizarrement mentionnée nulle part.

Pour les forms, oui avoir un type apr formulaire est souvent adapté. Voir ce qu'a dit Nek a ce sujet. Et pour le data_class, les opinions varient énormément en fait… Soit on fait des commandes comme l'a indiqué MatTheCat, soit on manipule directement les "entités" qui sont en fait des values objects en soit (c'est ce que je préfère personnellement, ça m'évite de devoir manipuler mon entité par la suite si jamais j'ai besoin de sauvegarder ces données dans ma base)

C'est ce que je fais quand je peux, c'est clairement plus simple, mais ici c'est probablement impossible, il y a plusieurs entités en jeu au moment où je veux créer une discussion :

• L'entité Discussion, qui contient le titre, ainsi que la date et l'username du dernier post
• L'entité Post, qui contient un message, son auteur et la date d'envoi
• L'entité Participant, qui fait le joint entre les utilisateurs et les discussions. J'en ai besoin entres autres pour marquer qui a lu ou pas lu ses messages, ce qui est apparament impossible avec une relation ManyToMany directe.

ET donc quand on veut lancer une nouvelle discussion, il faut :

• Créer une discussion
• Créer un post
• Créer deux (ou plus) de participants
• Ajouter le post à la discussion
• Ajouter les participants à la Discussion
• Persister le tout en même temps !

LE titre et le contenu étant dans deux entités différentes, je ne vois pas comment on pourrait faire autrement. Et il y a encore les destinataires à gérer.

Je ne vois pas trop le rapport avec le design pattern commande, que j'ai d'ailleurs déjà plus ou moins utilisé en Java et C++; mais je vous fais confiance.

Merci pour vos réponses. Je crois qu'on peut considérer ce sujet comme résolu maintenant.

cette ligne a pour effet de rediriger vers le formulaire de login fourni par FOSUserBundle

Nope, ça c'est géré par le firewall de Symfony. Quand tu en définis un avec un formulaire d'authentification alors tout utilisateur non authentifié traité par le firewall sera redirigé sur le formulaire, ce avant le code de ton contrôleur.

Concernant les commandes, le principal avantage est le découplage entre formulaire et entité, ce qui permet de quitter le CRUD pour se rapprocher du DDD, généralement ça rend le code plus propre. Mais au final je ne suis pas sûr que ça aide dans ton cas…

Dans ce contexte très précis. Sinon hors contexte, le rhum est différent du whisky, oui.

"Il ne levera pas plus le petit doigt quoique tu fasses". L'implicite, ça te parle ? Bien sûr qu'il "écoute" (c'est son rôle), mais quoique tu lui dises, quoique tu fasses, ce sera la même chose : un bon gros NOPE.

Vu ce que je t'ai linké… là c'est de la mauvaise foi hein.

Oui on encourage le mec a se connecter différement (un autre compte par exemple, qui lui aura les accès). C'est juste que le type actuel n'a pas les droits pour. Comme je l'ai déjà dit (Encore une fois…), un serveur t'authentifie systématiquement… Faut dépasser un peu le cadre du "login / mdp" ici

"qui que tu sois" est normalement suffisement explicite pour dire que peu importe que tu ai un certain degré d'autorisation ou non… Tu n'as pas accès a la ressource, point final. Quand tu mets une restriction sur un repertoire /private, ou que t'essayes d'accéder à une ressource hors d'accès (même si t'es la personne qui a le plus de droit - d'ou le "qui que tu sois"), là tu te mange une 403. T'auras beau essayer de te connecter avec d'autres comptes, ca sera le même résultat : NOPE.

C'est pas comme si je disais ça depuis le debut. Oh wait…

Ben ton post / discussion, y'a bien un lien non ? Du coup dans ton form type du post tu as bien un champ "discussion" (de type entité) ou quelque chose du genre, non (en hidden, … peu importe) ?

Ici le pattern command n'a pas grand chose à voir au final. C'est juste que tu si tu veux pas manipuler des données temporaires dans ton (tes) entité(s), avoir un truc clean a la fin (un arbre de commandes qui a deja validé ta data de maniere uniforme). Mais bref, je suis d'accord avec MatTheCat poru le fait que je doutes que t'aides vraiment ici…

Dans ce contexte très précis. Sinon hors contexte, le rhum est différent du whisky, oui.

Donc dans un contexte le rhum est du whisky ? Raisonnement faux, conclusion fausse.

L'implicite, ça te parle ?

Pas quand on se targue de "débattre" d'une RFC.

quoique tu lui dises, quoique tu fasses, ce sera la même chose : un bon gros NOPE.

Ben non, pourquoi refuser l'accès à une ressource si l'utilisateur à l'autorisation ?

un serveur t'authentifie systématiquement

WAT

Faut dépasser un peu le cadre du "login / mdp" ici

Justement non. Je cite la RFC :

The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource.

If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials.

Tu sais ce que veux dire credentials ? "Identifiants". Genre login/mdp, tu vois ?

Tu n'as pas accès a la ressource, point final.

WTF mais tu vois ça où ? Y'a pas que dans le cas d'une tentative de listing qu'on retourne une 403. On retourne une 403 quand on n'autorise pas une requête. Genre quand un utilisateur ne participe pas à une discussion il n'a pas accès à la discussion. Mais s'il en fait partie il y a accès ! Je cite encore une fois la RFC :

If authentication credentials were provided in the request, the server considers them insufficient to grant access. […] The client MAY repeat the request with new or different credentials.

Arrête d'interpréter et lis !

Dans ce contexte très précis. Sinon hors contexte, le rhum est différent du whisky, oui.

Donc dans un contexte le rhum est du whisky ? Raisonnement faux, conclusion fausse.

Dans un certain contexte, les deux sont de l'alcool. CQFD.

quoique tu lui dises, quoique tu fasses, ce sera la même chose : un bon gros NOPE.

Ben non, pourquoi refuser l'accès à une ressource si l'utilisateur à l'autorisation ?

Ben justement, il aura JAMAIS l'accès, quel que soit son level d'autorisation ! C'est ce que je me tue à te dire depuis tout à l'heure

un serveur t'authentifie systématiquement

WAT

Faut dépasser un peu le cadre du "login / mdp" ici

Justement non. Je cite la RFC :

The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource.

If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials.

Tu sais ce que veux dire credentials ? "Identifiants". Genre login/mdp, tu vois ?

Encore une fosi dans ce contexte, "having credentials" veut aussi dire "avoir des accès". Tiens le meilleur exemple au monde ; certaines machines, quand tu essayes de te connecter en ssh dessus, peuvent filtrer aussi par ip pour se connecter dessus, même si tn login / mdp est bon. Tu n'as pas les "credentials" comme tu dis, car il y a un autre facteur (adresse ip) qui t'empeche alors de te connecter ; t'aura beau être root de la machine, elle en aura rien à battre et m'acceptera jamais de te connecter. C'est ce genre de "Forbidden" que la 403 HTTP veut remonter.

Tu n'as pas accès a la ressource, point final.

WTF mais tu vois ça où ? Y'a pas que dans le cas d'une tentative de listing qu'on retourne une 403. On retourne une 403 quand on n'autorise pas une requête. Genre quand un utilisateur ne participe pas à une discussion il n'a pas accès à la discussion. Mais s'il en fait partie il y a accès ! Je cite encore une fois la RFC :

If authentication credentials were provided in the request, the server considers them insufficient to grant access. […] The client MAY repeat the request with new or different credentials.

Arrête d'interpréter et lis !

le "MAY" en gros devrait aussi te mettre sur le chemin hein. C'est "POSSIBLE" de répéter, mais pas GARANTI que ça marche. En bref (et encore une fois c'est ce que je dis depuis le début…), OSEF DE TON LOGIN/MDP

Moi je m'arrête là, j'ai l'impression de parler à un mur…

Dans un certain contexte, les deux sont de l'alcool. CQFD.

WTF??? Hey, dans un contexte un arrosoir et une comète sont deux objets, donc dans un certain contexte une automobile est une carotte. CQFD.

Non. Stop.

Ben justement, il aura JAMAIS l'accès, quel que soit son level d'autorisation ! C'est ce que je me tue à te dire depuis tout à l'heure

Tu peux te tuer ça sera toujours faux.

dans ce contexte, "having credentials" veut aussi dire "avoir des accès".

"contexte" n'est pas un mot magique qui te permet de justifier n'importe quoi. Déjà je ne sais pas d'où tu sors cette expression, mais de toute façon credentials veut dire "identifiants". Arrête de croire que les mots se traduisent comme tu le veux.

Tiens le meilleur exemple au monde ; certaines machines, quand tu essayes de te connecter en ssh dessus, peuvent filtrer aussi par ip pour se connecter dessus, même si tn login / mdp est bon. Tu n'as pas les "credentials" comme tu dis

Si, le login / mdp. C'est toi qui confonds authentification et autorisation. Les identifiants permettent l'authentification.

il y a un autre facteur (adresse ip) qui t'empeche alors de te connecter

Ça c'est l'autorisation.

t'aura beau être root de la machine, elle en aura rien à battre et m'acceptera jamais de te connecter.

Ben si, suffit de se connecter d'une autre IP.

le "MAY" en gros devrait aussi te mettre sur le chemin hein. C'est "POSSIBLE" de répéter, mais pas GARANTI que ça marche.

Si c'est pas garanti ça veut dire que ça peut marcher, monsieur "il aura JAMAIS l'accès".

OSEF DE TON LOGIN/MDP

Où tu vois mention de login/mdp dans la définition de la 403 oO Ah sans doute dans ton "contexte" ?

Bon du coup je suis toujours pas sûr que tu trolles, mais j'espère vraiment. Ou alors tu vis dans ton monde dans lequel tu n'as rien besoin de comprendre pour être persuadé que tu as raison. Dans les deux cas ce n'est pas la peine d'essayer de t'expliquer.

@Nek une petite connerie à ajouter ? Moi j'ai terminé.

Je ferme le sujet temporairement, le temps que les esprits s'apaisent et d'évaluer si des sanctions sont de rigueur.

Bon, peu importe qui a raison ou tort, ce sujet n'a pas à être un défouloir de provocs envers l'un ou l'autre (j'en cite une pour l'exemple, celle de MatTheCat, "@Nek une petite connerie à ajouter ? Moi j'ai terminé.") ou d'être particulièrement borné/agressif/acide dans ses réponses (je ne cite pas d'exemples, suffit de lire le sujet).

Si vous estimez qu'un membre va trop loin, vous signalez, sans poster ou si vous sentez la t° corporelle chauffer, allez prendre l'air et respirez un bon coup. Mais ce genre de défouloir, de prises de tête, non. Juste non. Comme personne n'a d'antécédents (entre guillemets), je laisse passer pour cette fois mais que ça ne se reproduise plus svp.

Je laisse le sujet ouvert, sait-on jamais qu'à l'avenir un membre tombe dessus et souhaite poser une question similaire.

Ben ton post / discussion, y'a bien un lien non ? Du coup dans ton form type du post tu as bien un champ "discussion" (de type entité) ou quelque chose du genre, non (en hidden, … peu importe) ?

Ben, même pas.

• Quand on répond, l'ID de la discussion est dans l'URL, donc je n'ai même pas besoin du champ hidden. ET tant mieux, ça évite des failles à la con genre je poste dans un topic qui ne m'appartient pas; je n'ai pas besoin de faire cette vérification dans deux contrôleurs au risque d'en oublier un.
• ET quand on crée une nouvelle discussion avec un premier post, elle n'existe pas encore, son ID n'est pas connu (il faut la créer, justement).

Par contre au niveau entité, bien sûr qu'il y a un lien: Discussion -> (OneToMany) -> Post.

Nope, ça c'est géré par le firewall de Symfony. Quand tu en définis un avec un formulaire d'authentification alors tout utilisateur non authentifié traité par le firewall sera redirigé sur le formulaire, ce avant le code de ton contrôleur.

C'est pas si simple je pense. Certaines pages ne nécéssitent pas d'être connecté pour y accéder. Pour le firewall j'ai laissé le code par défaut proposé par FOSUserBundle / les tutorials du book, sans trop comprendre ni trop chercher.

En tout cas si j'enlève la ligne, j'arrive bel et bien à afficher la page sans être identifié. Donc j'en conclus que c'est bien elle qui fait la redirection si nécessaire.

Concernant les commandes, le principal avantage est le découplage entre formulaire et entité, ce qui permet de quitter le CRUD pour se rapprocher du DDD, généralement ça rend le code plus propre.

DDD ?

Le concept des firewalls est simple en fait ; quand Symfony traite une requête il vérifie si cette dernière passe dans un firewall. La vérification porte généralement sur l'URL mais ça peut être n'importe quoi d'autre avec un RequestMatcher. Une fois dans un firewall la configuration de ce dernier indique si l'utilisateur doit être authentifié ou pas, et si oui, comment. Dans ton cas l'authentification passe par un formulaire de connexion, donc si l'utilisateur n'est pas authentifié il est redirigé vers ce dernier.

Sinon DDD signifie Domain Driven Design, en gros c'est une méthodologie qui calque le comportement des objets de ton "domaine" (par exemple ici discussion et post) à tes classes. Concrètement au lieu d'un setter par attribut tu auras par exemple une méthode factory start dans ton objet Discussion qui prendra un Post en argument. Quand tu écriras le code ça donnera donc littéralement "commence une discussion avec ce post". Concrètement ça aide à la lisibilité du code et à la stabilité des entités. Par contre ces objets ne s'intègrent pas du tout avec les formulaires de Symfony puisque ceux-ci hydratent "bêtement" attribut par attribut. D'où les commandes qui permettent en plus de séparer l'action en elle-même des objets concernés.

Comme je disais je ne sais pas si c'est pertinent dans ton cas mais pour avoir testé ça rend généralement les choses plus propres et plus simples.