Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pouvoir lancer le script de reset à la demande #12

Open
tuxayo opened this issue Sep 11, 2015 · 8 comments
Open

Pouvoir lancer le script de reset à la demande #12

tuxayo opened this issue Sep 11, 2015 · 8 comments
Assignees

Comments

@tuxayo
Copy link
Contributor

tuxayo commented Sep 11, 2015

Lors du clone/DL
La date du fichier est la date courante
Donc il n'est pas possible de le reset

@papjul
Copy link
Owner

papjul commented Sep 11, 2015

Comme indiqué dans la doc, tu peux mettre (temporairement) la variable DEBUG à true pour faire tous tes tests, cf https://github.com/papjul/ade-planning-viewer#identifiant-resetyaml-et-identifier
Je réflechis à comment mieux protéger les attaques sur ce fichier, le « temps minimum » entre deux appels ne me semble pas la meilleure, mais c’est au moins la plus efficace…

@tuxayo
Copy link
Contributor Author

tuxayo commented Sep 11, 2015

tu peux mettre (temporairement) la variable DEBUG à true pour faire tous tes tests

Ça marche aussi. Je réfléchis à comment mettre dans la doc ça ou l'utilisation de touch. Pour indiquer qu'il faut s'en occuper car cela va arriver à chaque nouvelle install.

Je réflechis à comment mieux protéger les attaques sur ce fichier

On pourrait facilement DOS le serveur en spammant de "GET /reset.php" ?

@papjul
Copy link
Owner

papjul commented Sep 11, 2015

Le fichier reset.yaml est pas censé être configuré de base, donc tu es censé lire toute cette partie.

Oui, tu pourrais avoir un comportement suspect, par le biais de ton serveur tu ferais des requêtes régulièrement sur le serveur AMU, et ce serait TON serveur qui serait inculpé. Sans aller jusqu’au DDoS d’AMU (ton serveur aura planté avant), l’IP de ton serveur apparaîtrait comme très suspecte auprès du serveur d’AMU qui pourrait automatiquement ou manuellement te bannir (fail2ban) et alors là tu pourrais plus reset automatiquement :(

@papjul papjul self-assigned this Sep 12, 2015
@papjul papjul changed the title Installation: Ne plus devoir changer la date de modif du fichier "identifier" à la main Améliorer la sécurité du reset Sep 23, 2015
@papjul papjul removed the question label Sep 23, 2015
@tuxayo
Copy link
Contributor Author

tuxayo commented Oct 4, 2015

Même en lisant la doc, il faut dans tout les cas changer le timestamp où mettre le mode debug pour la première utilisation

@tuxayo
Copy link
Contributor Author

tuxayo commented Oct 4, 2015

Alors que ça ne semble pas nécessaire quand on la lit.

@papjul
Copy link
Owner

papjul commented Oct 6, 2015

Qu'est-ce qui te fait penser ça ? La présentation de l'identifiant laisse bien penser que c'est obligatoire et présente deux manières de le (ré)initialiser. Si tu suis les instructions dans l'ordre pour préparer le reset, tu initialiseras une première fois l'identifiant. Tu n'as pas eu à le faire parce que je t'ai préparé le reset. Mais je pourrais faire deux dépôts, un avec le code et un avec un exemple. Mais je garde l'issue ouverte pour trouver une meilleure sécurité alternative.

@tuxayo
Copy link
Contributor Author

tuxayo commented Oct 6, 2015

À oui quand on setup reset.php on se met en DEBUG et le problème n’apparaît pas. Pas bien lu la doc, my bad!

@papjul papjul changed the title Améliorer la sécurité du reset Pouvoir lancer le script de reset à la demande Jun 20, 2020
@papjul
Copy link
Owner

papjul commented Jun 20, 2020

Une solution pourrait être d’autoriser les resets qui sont lancés via la ligne de commande PHP.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants