Der einzigste Bugtracker, den ich bisher gefunden habe, der brauchbar ist, ist bts von Debian. Das Teil iss genial, läßt sich völlig von der Kommandozeile steuern und alles läuft via Mail.
All diese Web-based Bugtracker funktionieren doch die hälfte der Zeit nicht. Und wenn, dann nur, wenn man Javascript, Flash, Cookies und was weiß ich was sonst noch einschaltet.
Kommt auf den Einsatzzweck an. BTS würde ich unseren Kunden nicht vorsetzen wollen. Wir nutzen Redmine, und sind seit Jahren zufrieden. Und Webseiten die JavaScript und Cookies benötigen sind normal. Wer bitte macht eine Seite mit Authentifizierung ohne Cookies? Session IDs in URL?
Von UnwichtigerUser am Sa, 15. April 2017 um 08:57 #
Hmm.. Weshalb benötige ich für jeden Sche… ein Webfrontend?
Nett, wenn eines da ist, aber in den meisten Fällen komplett verzichtbar.
Und, gegen Kekse ist nichts einzuwenden, wenn sie sparsam und mit korrektem Anwendungszweck verwendet werden. Aber dann muß eine Seite das auch explizit kundtun und auch erklären, warum. Und nicht einfach tausende von Trackingkekse setzen.
Daneben gibt es noch andere Möglichkeiten als Kekse und ID in der URL. Beispielsweise Basic-Auth oder versteckte Felder oder …
Von kamome umidori am Sa, 15. April 2017 um 14:00 #
> Webseiten die JavaScript […] benötigen sind normal
Das macht es aber nicht sicherer oder weniger "falsch". Für Webapps, denen Du vertraust, kann JS eine gute Lösung sein, auf einer öffentlichen Website hat das nichts zu suchen (bzw. niemand sollte das jemals ausführen (müssen)) – seufz, ja, ich weiß. (ein interessantes Beispiel (von vielen) für die sicherheitstechnisch katastrophalen Möglichkeiten von JS: Samy Kamkars "How I met your girlfriend")
Alle angegebenen sind ein Pain in the Ass!
Der einzigste Bugtracker, den ich bisher gefunden habe, der brauchbar ist, ist bts von Debian. Das Teil iss genial, läßt sich völlig von der Kommandozeile steuern und alles läuft via Mail.
All diese Web-based Bugtracker funktionieren doch die hälfte der Zeit nicht. Und wenn, dann nur, wenn man Javascript, Flash, Cookies und was weiß ich was sonst noch einschaltet.
Kommt auf den Einsatzzweck an. BTS würde ich unseren Kunden nicht vorsetzen wollen. Wir nutzen Redmine, und sind seit Jahren zufrieden. Und Webseiten die JavaScript und Cookies benötigen sind normal. Wer bitte macht eine Seite mit Authentifizierung ohne Cookies? Session IDs in URL?
Hmm.. Weshalb benötige ich für jeden Sche… ein Webfrontend?
Nett, wenn eines da ist, aber in den meisten Fällen komplett verzichtbar.
Und, gegen Kekse ist nichts einzuwenden, wenn sie sparsam und mit korrektem Anwendungszweck verwendet werden. Aber dann muß eine Seite das auch explizit kundtun und auch erklären, warum. Und nicht einfach tausende von Trackingkekse setzen.
Daneben gibt es noch andere Möglichkeiten als Kekse und ID in der URL. Beispielsweise Basic-Auth oder versteckte Felder oder …
> Webseiten die JavaScript […] benötigen sind normal
Das macht es aber nicht sicherer oder weniger "falsch". Für Webapps, denen Du vertraust, kann JS eine gute Lösung sein, auf einer öffentlichen Website hat das nichts zu suchen (bzw. niemand sollte das jemals ausführen (müssen)) – seufz, ja, ich weiß.
(ein interessantes Beispiel (von vielen) für die sicherheitstechnisch katastrophalen Möglichkeiten von JS: Samy Kamkars "How I met your girlfriend")