“Not accepted” would mean they get refused. Do you have a error log of it?
If you mean they get ignored, do the configuration files revert back to default? If so, stop the nodered service, alter the files, then start the service again.
(Showing what are those alterations you require might help me, too 
)
Hello,
not accepted mean that I edit the configs.js file and restart the Node-RED server, but in the web interface isn’t any change, but in the file the changes are already there.
But I’ve got an idea: I can use MQTT instead of webhooks.
Thanks your help
Upgrade to v1.3.3, Maintenance release (changelog)
Backup before changing URL, and handle failing URL change
Remove is_public argument and silence npm warnings during installationEnjoy!
Is there a (little) tutorial somewhere to get the dashboard function working?
I get a 404 not found when I try to open the page.
I did install the dashboard from the palette menu in Node-Red.
EDIT
after restarting the server and waiting a little, the ui comes up. 
Hum… weird. It works out-of-the-box when I install it with the palette. 
Salut tituspijean,
Merci pour ton super boulot de packaging de Nodered pour Yuno ! 
J’utilise Node-RED assez couramment hors de YunoHost. J’utilise souvent des end-points (bloc http in) et je vois que si on protège son Node Red avec Yuno, on se retrouve avec des end-points protégés, c’est à dire inaccessibles. 
Du coup, comme j’en ai déjà l’habitude, j’ai voulu utiliser la protection classique de Node-RED à la place (en laissant Node-RED accessible aux visiteurs YunoHost) ce qui consiste à décommenter les lignes suivantes du fichier
/opt/yunohost/nodered/data/settings.js (que j’ai eu bien du mal à trouver d’ailleurs, je ne sais pas où c’est documenté)
// Securing Node-RED
// -----------------
// To password protect the Node-RED editor and admin API, the following
// property can be used. See http://nodered.org/docs/security.html for details.
//adminAuth: {
// type: "credentials",
// users: [{
// username: "admin",
// password: "xxx",
// permissions: "*"
// }]
// },
Puis de redémarrer Node-RED pour voir le résultat avec
systemctl restart nodered
et en vérifiant le bon redémarrage de Node-RED avec
systemctl status nodered
Malheureusement, même si l’accès aux flows est effectivement bloqué par la demande de login/mot de passe de Node-RED (classique), aucun mot de passe ne fonctionne jamais. Je les encrypte comme d’habitude pourtant. Mais j’ai toujours ‘login failed’ 
Autre idée :
J’ai essayé de changer les primitives (toujours dans /settings.js)
httpAdminRoot: '/red'
httpNodeRoot: '/nodered'
à la place de
httpRoot: '/nodered'
Et de laisser accessible aux visiteurs YunoHost + ne pas mettre de mot de passe Node-RED.
De cette façon j’ai bien les end-points accessibles aux visiteurs (via https://mon host/nodered/nom du end-point) et la demande de login mot de passe de Yuno pour accéder aux flows quand je tape https://mon host/red/ mais quand je saisi mon login/mdp, je tombe sur l’interface utilisateur (avec les tuiles de toutes mes apps) et pas sur mes flows Node-RED. Il doit y avoir de l’url rewriting dans YunoHost qui m’empêche de définir un chemin /red. 
Bref je suis un peu bloqué pour protéger mes flow mais laisser l’accès à mes end-points. Aurais-tu par hasard une idée ?
Merci beaucoup à toi
Précision importante, il y a une erreur dans la console javascript quand on tente de se loguer qui explique certainement le ‘login failed’ :
vendor.js:2 POST https://xxxxxxxxxx/nodered/auth/token 403
Si tu veux des infos complètes sur ton app: yunohost app info nodered -f
Alors sinon, pour répondre à ta demande… Dans mes souvenirs, j’avais eu pas mal de soucis pour configurer au poil NGINX, les permissions et Node-RED.
Je peux te proposer une solution qui implique moins de bidouille (et que je pourrai pérenniser dans une prochaine version de l’app):
httpNodeRoot: '/red-nodes' (ou le chemin que tu préfères)app=nodered
source /usr/share/yunohost/helpers
ynh_permission_create --permission "nodes" --url "/red-nodes" --allowed "visitors" --label "Nodes endpoints"
Edit: fonctionnalité ajoutée dans la version testing: Update to v2.0.4, templates, and add permissions by tituspijean · Pull Request #28 · YunoHost-Apps/nodered_ynh · GitHub
Call for testers!
Upgrade to v1.3.5
Adding nodes permission to allow to use HTTP nodes at /path/red-nodes/<node> (dedicated to @starcrouz) Update the issue and PR templatesInstructions to test are in the first post. Feedback is most welcome. 
Bonjour tituspijean, merci pour ta réponse super rapide.
J’avoue que ce qui a été le plus galère ça été de comprendre que sous /opt/yunohost/nodered il y avait 2 settings.js et que le bon était celui caché sous data :-/. En tapant ta commande yunohost app info nodered -f, je n’ai pas vu ça non plus. Mais merci bcp pour cette commande de toutes façons.
Merci pour ta solution et encore plus pour ton nouveau package à tester ! C’est trop d’honneur :-)) !
J’ai donc modifié les settings de Nodered tel que
httpAdminRoot: '/nodered'
httpNodeRoot: '/red-nodes'
(impossible de réutiliser les settings d’origine httpRoot: ‘/nodered’ il me semble, car cela fixe httpAdminRoot = httpNodeRoot. Je me trompe ?)
J’ai donc mis à jour (branche testing) mon Node-RED sur Yuno via la commande (j’ai du remplacer nodered_ynh par nodered pour que cela fonctionne):
sudo yunohost app upgrade nodered -u https://github.com/YunoHost-Apps/nodered_ynh/tree/testing --debug. Puis je redémarré Node-RED.
Je suis donc en Node-RED 1.3.5 et j’ai vu ton nouveau réglage au sujet des end-points (génial !). J’ai aussi modifié les autorisations Yuno des utilisateurs tel que les visiteurs aient un accès libre à l’UI et aux end-points (/red-nodes/) de node-RED mais pas aux flows. Et j’ai ajouté l’UI et les End-points à l’interface utilisateurs (tuiles).
Lors de mes tests :
Cannot GET /nodered/ui & Cannot GET /nodered/nodered/red-nodes. Bien entendu, j’ai un flow qui comprend un élément d’UI (sous un groupe>tab) et un End-point de test appelé kiki. J’ai donc aussi essayé d’uatres URLs et j’ai obtenu : Cannot GET /nodered/nodered/red-nodes/kiki, Cannot GET /nodered/red-nodes/kiki et même /red-nodes/kiki qui me renvoie directement à l’interface utilisateur (les tuiles).Je me suis ensuite déconnecté de mon utilisateur Yuno (je deviens donc un visiteur). Et quelque soit l’url je suis routé vers le login/mdp yuno ou vers des Cannot GET.
J’ai commencé à douter de mes tests et du coup j’ai installé un second Node-RED sur Yuno (dans un sous-domaine) en version master. Et j’arrive très bien à faire fonctionner l’UI (l’accès au dashboard fonctionne depuis la tuile) et /nodered2/kiki fonctionne très bien aussi (mais seulement quand mon utilisateur est connecté donc mon End-point est inaccessible aux visiteurs. Mon problème de départ).
Merci encore pour cette modif et j’espère que mes tests sont suffisamment clairs et surtout reproductibles.
A bientôt
En désespoir de cause, j’ai aussi tenté ta bidouille sur ma 2nd install de Node-RED (master). Je tape donc
app=nodered__2
puis
source /usr/share/yunohost/helpers
mais j’obtiens :
basename: invalid option – ‘b’
Try ‘basename --help’ for more information.
Merci pour tes tests et retours ! Pense bien à faire une sauvegarde, au cas où on casse tout…
Arf, désolé pour ça. 
L’info doit être cachée quelque part dans la doc de Node-RED. Je ne fais que me plier à leurs choix de conception. 
Comme indiqué dans les commentaires dans le fichier settings.js, httpRoot est prioritaire sur les deux autres:
// The following property can be used in place of ‘httpAdminRoot’ and ‘httpNodeRoot’,
// to apply the same root to both parts.
//httpRoot: ‘/’,
Dans ma MAJ de test, je re-commente httpRoot. 
Alors non, c’est le comportement de base des tuiles et des permissions. Un utilisateur ne voit une tuile que s’il a la permission associée. Cependant, considérant que le chemin et la permission nodes est plutôt réservé aux non-humains (bots, autres apps, …), je m’étais dit qu’on pouvait la maintenir masquée quoi qu’il arrive (et 3 tuiles pour une app, je trouve ça beaucoup 
). Je comptais donc la masquer, j’ai dû oublier un paramètre.
Alors, j’ai découvert une erreur dans leur fichier settings.js, ou du moins il y a eu un changement entre temps…
ui
The home path for the Node-RED-Dashboard add-on nodes can specified. This is relative to any already defined httpNodeRoot
alors que le fichier settings dit
// If you installed the optional node-red-dashboard you can set it’s path
// relative to httpRoot
ui: { path: “ui” },
Et évidemment c’est le site qui est correct. Donc l’adresse du dashboard deviendrait /nodered/red-nodes/ui. C’est pas joli, mais ça marche.
Je me tâte de changer un peu les adresses, mais j’ignore si ça va pas tout faire péter chez les autres utlisateurs:
/nodered/admin pour l’éditeur/nodered/ comme racine pour les nodes, donc pour /nodered/kiki ou /nodered/uiWow, je ne sais pas d’où ça sort ça… tu utilises bien bash?
Oui, pour les url ce serait très bien. Mais pour l’instant je n’en ai aucune qui marche (sauf l’accès aux flow) : ni UI, ni les end-points. Comment je pourrais faire pour les faire fonctionner depuis ta version de test (sans attendre tes modifs) ?
Apparemment, le shell que j’utilise sur ma Debian 10 est bien bash :
ls -l /proc/$$/exe
lrwxrwxrwx 1 admin 1007 0 May 25 17:21 /proc/17728/exe → /usr/bin/bash
(Re-)call for testers!
Upgrade to v1.3.5 main permission now protects
/path which serves the dashboard (now automatically installed)/path/<node>
Adding admin permission to protect the editor at /path/admin
Update the issue and PR templatesTo test:
yunohost app install https://github.com/YunoHost-Apps/nodered_ynh/tree/testing or yunohost app upgrade nodered -u https://github.com/YunoHost-Apps/nodered_ynh/tree/testing
Feedback is most welcome.
@starcrouz tu peux mettre à jour avec cette version. Comme tu as fait des bidouilles manuelles on fera une revue séparément si besoin.
Salut tituspijean,
Je me suis fait une nouvelle install en CLI de ta PR28 et ta nouvelle approche me semble très efficace : quand on donne les droits d’accès à Node Red aux visiteurs (mais pas à l’admin de Node Red), le Dash board et les end points sont accessibles tous les 2. C’est parfait !
C’est super aussi de ne pas avoir à installer de Dashboard.
Merci à toi !
New release! PR34
Upgrade to v2.0.6
main permission now protects /admin, the flows editor ui permission now protects /ui, which serves the dashboard (now automatically installed) endpoints permission now protects / (no tile displayed in the SSO, it is for API-like endpoints)
Update the issue and PR templates, and the DISCLAIMER
Use the DESCRIPTION file Create an automated PR whenever a new version is available upstream.
Since this version changes the permission system, please check that they suit you in your YunoHost administration panel.
@starcrouz j’ai encore changé les permissions, protéger le tableau de bord et les API avec la même permission ne me plaisait pas.