Design & Développement web - Le topic des canards qui mangent des cookies

[Awake]

Je les déclare au niveau de ma classe en private : private toto: string

Ben à ce moment elle est pas globale du tout ta variable

En tout cas tu devrais pouvoir y accéder avec "this.toto" dans ta méthode. Mais attention avec this en javascript, qui a tendance à référencer tout et n'importe quoi, notamment si tu commence à faire des appels dynamique à tes méthodes comme "instance.methode.call()".

[Dross]

Il est en Typescript, le this est sûr tant qu'il déclare bien ses méthodes.

@deathdigger Tu pourrai nous donner le bout de code (comment t'a déclaré la variable et la méthode) histoire qu'on y regarde ?

[tenshu]

Parmi les canards qui font du Symfony, il y en a qui en ont déployé sur du Platform.sh ?

Techniquement, sur le papier ça a juste l'air... idéal. Par contre côté tarif c'est très opaque.

J'ai jamais utilisé mais pour le coup je trouve pas le pricing opaque, cher oui mais pas opaque.

[Orhin]

Il est en Typescript, le this est sûr tant qu'il déclare bien ses méthodes.

@deathdigger Tu pourrai nous donner le bout de code (comment t'a déclaré la variable et la méthode) histoire qu'on y regarde ?

Idem, là ça me parait pas très clair (enfin si, je suis rassuré que ce soit pas vraiment des variables globales ).

[GrandFather]

J'ai jamais utilisé mais pour le coup je trouve pas le pricing opaque, cher oui mais pas opaque.

Tu as pu trouver une grille tarifaire complète sur leur site ? C’est peut-être moi qui cherche mal, mais si c’est le cas c’est pas vraiment mis en avant... J’ai une visio prévue prochainement avec un de leurs commerciaux, je vais lui en faire part.

Pour le coup Amazon présente les tarifs de son cloud de manière plus directe et claire.

[tenshu]

Bah leur page pricing : https://platform.sh/pricing/

[deathdigger]

Ben à ce moment elle est pas globale du tout ta variable

En tout cas tu devrais pouvoir y accéder avec "this.toto" dans ta méthode. Mais attention avec this en javascript, qui a tendance à référencer tout et n'importe quoi, notamment si tu commence à faire des appels dynamique à tes méthodes comme "instance.methode.call()".

J'ai essayé avec le this et même en foutant un _this = this au début de la méthode, mais même résultat.

Ça ça marche (voir le shipmentCol dans l'appel de this.populateData) :


Mais si je le fais comme ça :


Et que j'ai ça dans ma méthode :


Ça ne marche pas (il est undefined).

[GrandFather]

Bah leur page pricing : https://platform.sh/pricing/

Comment j'ai pu louper ça... Après, leur commercial m'a confirmé que les tarifs pouvaient être affinés selon la taille du projet.

[Awake]

@deathdigger : je pense que c'est parce que tu utilise une fonction locale dans ton forEach(). Tout ce qui est inclus dans une function a un this dans le référentiel de la fonction. Si tu veux ne pas écraser le this dans ton forEach(), utilise une fonction flèche :

Oui :

list.getColumns().forEach((col) => {
    this.shipmentCol = ...; // this = instance de ta classe MW410Whatever
});

Non :

list.getColumns().forEach(function(col) {
    this.shipmentCol = ...; // this = contexte de ta closure/function locale
});

[poneyroux]

Un vrai sketch openclassroom.(Je fais une formation de dev web)
Je vais pas rentrer dans les détails mais entre mon mentor et mes évaluateurs ils vont me rendre dingue.

Je suis tombé sur ce post un peu par hasard, en regardant ce topic en diagonale.

J'ai fait une formation en front-end y a un peu plus de 2 ans, qui avait très bien commencé avec un mentor sympa, pédagogue, avec de bons conseils. Puis, il a arrêté parce qu'il avait une grosse mission en freelance et c'est àl où tout est parti en couille. J'suis passé sur l'exact opposé, un type sans aucune forme de pédagogie (à chaque question que je lui posais, il me répondait "réfléchis"), qui, à chaque fois qu'il relisait mon code, le réécrivait juste comme lui le ferait (sans faire de commentaires) et il était persuadé d'être le meilleur dév au monde, tout en s'étant même pas formé à ES6.

Les évals, ça c'est bien passé, mais j'ai clairement remis en question tout mon projet pro à cause de ce type et j'ai pris pas mal de temps avant de m'y remettre.
Et j'suis toujours énervé contre ce type aujourd'hui.

[deathdigger]

@deathdigger : je pense que c'est parce que tu utilise une fonction locale dans ton forEach(). Tout ce qui est inclus dans une function a un this dans le référentiel de la fonction. Si tu veux ne pas écraser le this dans ton forEach(), utilise une fonction flèche :

Oui :

list.getColumns().forEach((col) => {
    this.shipmentCol = ...; // this = instance de ta classe MW410Whatever
});

Non :

list.getColumns().forEach(function(col) {
    this.shipmentCol = ...; // this = contexte de ta closure/function locale
});

Super, merci !
Je viens de tester et ça marche. Dans un sens, c'est logique et on voit qu'à la compil, il va ajouter un var _this = this; dans le populateData.

[MrBeaner]

Question architecture réseau et sécurité

Hello les canards ! Je finis le développement de l'application web pour un de mes clients et j'aimerais bien quelques unes des lumières des gens plus expérimentés que moi

J'ai développé pour mon client une application avec le framework Remix (big up en passant, c'est vraiment génial comme outil, je recommande). Remix fonctionne ainsi : il traite les requêtes en renvoyant des fichiers HTML (du React rendu côté server) ou des json pour hydrater dynamiquement les pages.

Les admins réseau de mon client (une association avec un budget limité) ont l'habitude et le standard de travailler avec une architecture comme ça :



C'est du moins ce que j'ai compris de ce qu'ils veulent. À priori, ils préfèrent une application qui ait un serveur "front", qui reçoit les requêtes de l'extérieur et fetchent des json au serveur "back". Les membres du staff auraient un accès à l'application depuis le réseau interne de l'asso.

Avec Remix, pour le développement de l'application, ça n'aurait pas beaucoup de sens, à mon avis, pour l'utilisation des ressources budgétaires de faire 2 serveurs, avec des appels api à l'un ou l'autre.

Ma solution serait d'utiliser nginx comme front (comme forward reverse proxy) qui filtrerait les requêtes, an interdisant par exemple les requêtes à app.com/staff et seulement à app.com/user (ou pour limiter les connexions pour prévenir les attaques DDoS).

En échangeant avec les admins réseau, je n'ai pas entendu de problème concret de sécurité que je pourrais résoudre actuellement (ils ne sont pas devs, donc ils me parlent plutôt de standards qu'ils ne veulent pas lâcher). Est-ce que vous avez des recommandations ou de la documentation qui me permettrait de savoir sur quels problèmes de l'architecture je devrais me pencher ? Je suis habitué à héberger mes apps dans le cloud, sur GCP, Fly.io, etc... qui tournent des images docker sans me prendre la tête. D'ailleurs, à les entendre, ces solutions ne seraient pas sécures selon leurs standards.

Je profite volontiers de vos conseils et de votre XP C'est parfois frustrant de parler avec des admins réseaux et qui s'attendent à ce que je sois au top sur tout le spectre des applications web.

[Wobak]

Alors pour moi c'est un reverse proxy et pas un forward proxy.
nginx, traefik ou SWAG font bien le taf.

[Dross]

nginx ne serai pas une solution pour leur besoin (tel qu'exprimé) : la solution 2 serveurs privé/public est justement faite pour que les parties sensibles ne soient pas présentes physiquement sur la machine exposée au public, et donc plus à même de se faire compromettre. Une solution logicielle n'est donc en rien une solution à cette demande.

La seule solution c'est bien d'utiliser 2 serveurs (VPS/etc) distincts, avec les règles de sécurité en conséquence.

[MrBeaner]

Merci pour les retours ! Je précise que je ne suis pas obligé de répondre à leurs demandes en l'occurrence, donc je n'ai pas cette contrainte (s'ils ne veulent pas héberger, on peut aller chez Fly ou quoi).

J'essaie juste de me représenter des cas concrets qui seraient problématiques. Parce que sincèrement je n'arrive pas à voir comment quelque chose pourrait "entrer" dans le code et mettre le sou Aussi, je ne suis pas sûr que ce soit dangereux d'avoir son application sur Netlify ou quoi, parce qu'ils n'hébergent pas ainsi.

Pour être honnête, je ne trouve pas la demande raisonnable, est-ce que c'est par nooberie ?

[Dross]

C'est une question de sécurité : tu ne fait pas de la sécurité en ayant qu'une seule protection, tu en met le plus possible pour que si l'une d'entre elle lâche (faille 0 day, etc) ça ne soit pas open bar derrière. Faire ce genre d'isolation c'est une des manières de rajouter une protection (et une protection assez forte qui plus est), mais ça ne veux pas dire qu'il ne faut pas faire le reste non plus (ACLs, stratégie de mise à jour, réseaux virtuels, etc).

Au niveau du coté raisonnable ça dépends de ce qui est hébergé et du niveau de sécurité requis (et tout ça sera forcément relatif aux objectifs et valeurs de l'asso/entreprise).

Par exemple pour protéger des données sensibles / code sensible, c'est vraiment pas choquant de faire un serveur front accessible via internet, et un réseau virtuel privé en backend avec BDD / API sensibles / workers / etc. C'est même une bonne pratique. Comme ça, si le serveur public se fait hacker (et dans le monde de la sécurité, la question n'est pas de savoir "si" tu va te faire hacker mais "quand") ça ne donnera pas accès au code et données sensibles.

Après c'est ptet overkill pour l'asso si elle stocke juste des lolcats pour les 12-16 ans de l'école d'à coté, mais clairement c'est pas du tout une archi exotique.

[Wobak]

nginx ne serai pas une solution pour leur besoin (tel qu'exprimé) : la solution 2 serveurs privé/public est justement faite pour que les parties sensibles ne soient pas présentes physiquement sur la machine exposée au public, et donc plus à même de se faire compromettre. Une solution logicielle n'est donc en rien une solution à cette demande.

Heu je vois pas pourquoi nginx ne pourrait pas être une partie de la solution?

Si sur le serveur front tu as un reverse proxy qui n'autorise les requêtes vers le serveur interne que sur une seule URL, ça renforce la sécurité du bouzin. Ça ne veut pas dire qu'il ne faut pas mettre de sécurité ailleurs, mais je vois pas en quoi ça ne serait pas une solution?

[Dross]

Oui mais là si j'ai bien compris nginx n'aurai redirigé que vers un service roulant sur la machine elle même (pour éviter d'avoir les deux serveurs de l'archi proposée).

Mon point : on ne réponds pas à une demande de sécurité physique par du logiciel, mais bien sûr on utilisera quand même du logiciel dans l'histoire.

[MrBeaner]

Merci beaucoup en tout cas de me partager vos lumières les anciens C'est toujours cool pour un nouveau dev comme moi

[gros_bidule]

En gros c'est comme quand NCIS se fait pirater en plein épisode. McGee: holala, ils ont passé le premier pare-feu (comprendre : ils ont accès à la première machine A, qui cause à la B). Holala, ils ont passé le deuxième pare-feu ! (ils sont sur la B, mais ça va, le serveur de données est sur la C). Holala, ils ne faut pas que.... et là Gibs débranche la prise de courant de C.
Globalement c'est ça l'idée, non ? :ninja:

[Fastela]

https://shoelace.style/

La découverte du jour. Je suis très fan de l'approche Web Components / Framework-agnostic.

Je me demande si je vais pas utiliser un truc dans le genre pour ma prochaine app. Les librairies de composants sont encore trop à la traîne par rapport à Vue 3.

[GrandFather]

Les librairies de composants sont encore trop à la traîne par rapport à Vue 3.

Je ne sais pas lesquelles tu utilises, mais Element+ me semble très bien intégrer Vue3.

[raaaahman]

Hello,

pour les canards qui codent en TypeScript: ça vous est arrivé d'avoir à créer des définitions pour une bibliothèque JS que vous utilisez dans un projet en TS? Je suis grand confusion en ce moment.

J'ai fourchetté (fork en français?) la bibliothèque en question, j'y ajoute un fichier de déclarations index.d.ts (rien de fou):

Spoiler Alert!

// ... plusieurs exports nommés ...

declare interface YarnBound {
jump: (startAt: string) => void,
advance: (optionIndex: number) => void,
currentResult: Result
}

export default YarnBound

J'ajoute le chemin du fichier de définitions dans le package.json de la bibliothèque:

Spoiler Alert!

{
"name": "yarn-bound",
"version": "0.3.0",
"description": "Quality of life wrapper around bondage.js",
"main": "dist/yarn-bound.js",
"types": "src/index.d.ts",
// ...

Puis je l'importe dans mon projet; et là, le compilateur me dit:

'YarnBound' only refers to a type, but is being used as a value here.

Ben oui, j'ai typé le nom de la classe que j'utilise, mais c'était bien une classe dans la bibliothèque JS...

Que faut-il que je fasse? Que je compile la bibliothèque avec tsc? Que je publie le fichier de définitions à part dans l'organisation @types? Que je désactive le mode strict ?

[tenshu]

J'ai un nouveau taff et je fais un peu de R&D en utilisant le framework API Platform et franchement c'est plus que pas mal.

J'ai un peu de la peine à imaginer comment on peut avoir un truc plus efficace. Il y a juste la façon d'attacher du code métier à une action qui me chiffonne.

[GrandFather]

JJ'ai un peu de la peine à imaginer comment on peut avoir un truc plus efficace. Il y a juste la façon d'attacher du code métier à une action qui me chiffonne.

Ca dépend de la nature du code métier. Dans une appli j'avais couplé API Platform au composant Workflow de Symfony au travers de Providers custom, ça marchait très bien tout en restant une architecture REST.

Mais tu as d'autres approches, avec des extensions Doctrine, utiliser Messenger, des écouteurs d'événements...

[Dross]

Hello,

pour les canards qui codent en TypeScript: ça vous est arrivé d'avoir à créer des définitions pour une bibliothèque JS que vous utilisez dans un projet en TS? Je suis grand confusion en ce moment.

J'ai fourchetté (fork en français?) la bibliothèque en question, j'y ajoute un fichier de déclarations index.d.ts (rien de fou):

Ça fait longtemps que je l'ai pas fait, d'ailleurs je suis un peu étonné que tu veuille faire ça, c'est pour quel besoin, avoir l'autocomplétion ?

Car si c'est juste utiliser ta lib tu peux probablement juste l'importer avec "import * as Balbla from" et te débrouiller avec ?

[raaaahman]

Ça fait longtemps que je l'ai pas fait, d'ailleurs je suis un peu étonné que tu veuille faire ça, c'est pour quel besoin, avoir l'autocomplétion ?

Car si c'est juste utiliser ta lib tu peux probablement juste l'importer avec "import * as Balbla from" et te débrouiller avec ?

Le problème c'est que le mode "strict" du compilateur TypeScript me donne une erreur si j'importe un module sans déclaration:

TS7016: Could not find a declaration file for module 'yarn-bound'.

Je peux toujours désactiver le mode strict, mais je préférerais le garder. Je peux aussi écrire le fichier où je fais l'import en Javascript simple, mais je perds le typage pour tout ce qu'il y a dedans (mon store Redux).

"import * as Blabla" c'est un alias pour le nom du module il me semble, ça ne force pas son type, si?

[Dross]

Ça fait un type "any", donc le transpilateur arrêtera de t'emmerder, par contre oui, tu va perdre le typage. Par contre ça permet de charger à peut-prêt n'importe quoi. Si c'est ponctuel comme dépendance c'est pas super embêtant, si tu l'utilise dans 50% de ton code forcément c'est une autre histoire.

[Orhin]

Non mais tu peux aussi juste déclarer les types de ta dépendances dans ton projet, pas besoin d'aller modifier la librairie (sauf si tu veux contribuer tes types plus tard).

T'as cherché aussi si ta librairie avait pas déjà du typage "externe" (notamment via tous les "@types/toto") ?

[Wobak]

Merci beaucoup en tout cas de me partager vos lumières les anciens C'est toujours cool pour un nouveau dev comme moi

Attention je ne suis pas dev mais ingé systèmes, donc j'ai l'autre versant des infras