GitHub: Codesuche ohne Anmeldung nicht möglich

 (github.com/orgs)
1 Punkte von GN⁺ 2023-11-29 | 1 Kommentare | Auf WhatsApp teilen
  • In einer GitHub-Community-Diskussion wurde problematisiert, dass auch die Codesuche in öffentlichen Repositories ohne Anmeldung nicht mehr genutzt werden kann; der Fragesteller kritisierte, dies schade der Zugänglichkeit öffentlichen Codes und der Nutzbarkeit von Open Source
  • Ein GitHub-Maintainer antwortete, dass die Suche über alle Repositories hinweg schon seit Langem eine Anmeldung erfordert und dass GitHub diese Anforderung Anfang 2023 mit dem Ausbau der Suchfunktion auch auf die Suche in einzelnen Repositories ausgeweitet habe
  • Als Grund nannte GitHub, die Suchlast für Entwickler bewältigen zu müssen und zu reduzieren, dass Server durch anonyme Anfragen etwa von Bots überlastet werden
  • Diskussionsteilnehmer stellten infrage, ob die Anmeldepflicht zur Bot-Abwehr ausreicht, da öffentliche Repositories weiterhin geklont und lokal durchsucht werden können; als Alternativen wurden Rate Limits, CAPTCHA und Einschränkungen einfacher Suchvorgänge genannt
  • Praktisch können nicht angemeldete Nutzer Links zur Suche in öffentlichem Code nicht mehr direkt öffnen; daher wurden auch Umgehungswege wie grep.app, github1s, lokales grep, allgemeine Suchmaschinen und Spiegelung über mehrere Git-Forges diskutiert

Für die Suche in öffentlichem Code ist eine Anmeldung erforderlich

  • GitHub Community Discussion #77046 behandelt unter dem Titel „Can no longer search code without being logged in“ die Situation, dass Codesuche ohne Anmeldung nicht mehr möglich ist
  • Der Fragesteller erklärte, er habe auf einem älteren Gerät etwas in den eigenen Repositories suchen wollen, sei aber wegen der Anmeldepflicht nicht weitergekommen
    • Er habe Zugriff auf den Passwortmanager benötigt, außerdem 2FA und einen YubiKey; das alte Notebook habe jedoch keinen USB-C-Port gehabt
    • Er erklärte, er habe die Codesuche in öffentlichen Repositories für andere nutzbar machen wollen
  • Der Fragesteller kritisierte, dass es schwer nachvollziehbar sei, warum die Web-Codesuche eine Anmeldung erfordert, wenn öffentliche Repositories nach dem Klonen mit spezialisierten Tools durchsucht und analysiert werden können
  • Die Diskussion wurde durch die Antwort von GitHub als Answered markiert; auf der Seite werden 19 Kommentare und 58 Antworten angezeigt

GitHubs Antwort und offizielle Begründung

  • Der GitHub-Maintainer martinwoodward entschuldigte sich für die Unannehmlichkeiten und antwortete, dass die Suche über alle Repositories hinweg schon seit Langem eine Anmeldung erfordert
  • Er erklärte, dass GitHub die Anmeldepflicht Anfang 2023 mit dem Ausbau der Suchfunktion auch auf die Suche in einzelnen Repositories ausgeweitet habe
  • Hauptziel sei es, die Suchlast für GitHub-Entwickler zu bewältigen und zu verhindern, dass Server durch anonyme Anfragen etwa von Bots überlastet werden
  • Ein anderer Teilnehmer verwies in der Diskussion auf The technology behind GitHub’s new code search, einen Beitrag zur neuen Codesuche von GitHub

Kern der Kritik: öffentliche Repositories und Open-Source-Zugänglichkeit

  • Mehrere Teilnehmer sahen es als überzogen an, auch die Suche in öffentlichem Code per Login zu blockieren, da Code in öffentlichen Repositories ohne Anmeldung geklont werden kann
  • Ein Teilnehmer erklärte, es sei störend, dass externe Nutzer zu einem GitHub-Login gezwungen werden, um seinen öffentlichen Quellcode anzusehen
    • Er habe Suchabfragen wie repo:USER/REPO, path:... und AND NOT path:**/_externals als einzelne URL oder Schaltfläche teilen wollen
    • Wegen der Anmeldepflicht müsse er diese nun durch mehrere direkte Datei-URLs ersetzen
  • Andere Teilnehmer wiesen auf die Spannung zwischen GitHubs Selbstbeschreibung als „world's largest open source community“ und der Einschränkung der Suche in öffentlichem Code hin
  • Einige Kommentare erinnerten daran, dass es ähnliche Einschränkungen bereits vor der Übernahme durch Microsoft gegeben habe, und hielten entgegen, die Einschränkung sei nicht völlig neu

Bot-Abwehr und Kostendebatte

  • GitHub führte die Last durch anonyme Bot-Anfragen als Grund an, doch einige Teilnehmer argumentierten, eine Anmeldepflicht halte Betreiber spezialisierter Bots kaum auf
  • Als Alternative wurde vorgeschlagen, zunächst Rate Limits anzuwenden und erst beim Erreichen des Limits CAPTCHA oder Login zu verlangen
  • Als Gegenargument wurde genannt, dass Bots auf lokale Suche umsteigen könnten, da öffentliche Repositories anonym geklont werden können
    • Darauf entgegnete ein anderer Teilnehmer, dass Klonen nicht GitHubs Such-Computing nutzt und daher den Denial-of-Service-Vektor reduziert
    • Außerdem wurde angemerkt, dass geklonte Daten schnell veralten können
  • Falls die Suchkosten hoch seien, wurde auch eine Aufteilung vorgeschlagen: einfache Abfragen auf einfachere Weise für nicht angemeldete Nutzer anbieten und komplexe Abfragen angemeldeten Nutzern vorbehalten

Einschränkungen der Suchfunktion selbst und Vergleichsfälle

  • Ein Teilnehmer erwähnte, dass selbst im angemeldeten Zustand bei einer Suche über alle öffentlichen Repositories nach path:contributing.md nur fünf Ergebnisseiten angezeigt werden
    • Ein anderer Teilnehmer sagte, dies sei nicht nur ein Problem dieser konkreten Abfrage, sondern eine aktuelle Einschränkung der Suche, und verwies auf GitHub Community Discussion #9868
  • Ein anderer Teilnehmer verglich das Suchverhalten von SourceForge, Google Code archive, GitLab und Bitbucket
    • SourceForge und Google Code archive hätten keine Suche
    • GitLab verlange für die globale Suche eine Anmeldung, ermögliche aber die Suche pro Repository
    • Die Bitbucket-Suche leite zwar zum Login weiter, wenn man jedoch ein Repository finde, sei die Suche ohne Anmeldung möglich

Umgehungswege und Alternativdienste

  • Als Methode, um ein einzelnes Repository ohne Anmeldung schnell zu durchsuchen, wurde ein lokales Klonen mit anschließendem grep vorgeschlagen
    • Nach /dev/shm wechseln
    • git clone https://github.com/user/repo
    • Ins Repository wechseln und grep -r "pattern" . ausführen
    • Das Repository nach der Suche löschen
  • Für Mustersuchen über ganz GitHub hinweg wurde die Verwendung von "pattern" site:github.com in allgemeinen Suchmaschinen genannt
    • Zugleich wurde als Einschränkung genannt, dass dies nicht so mächtig ist wie die integrierte GitHub-Suche und möglicherweise nicht jeder Code indexiert ist
  • Als alternatives oder ergänzendes Tool wurde grep.app erwähnt, mit dem Repositories ohne Anmeldung durchsucht werden können
  • Ebenfalls geteilt wurde der Tipp, in einer GitHub-URL github.com durch github1s.com zu ersetzen, um das Repository in einer Online-VS-Code-Ansicht zu öffnen
  • Als alternative Git-Forges wurden GitLab, Framagit, Gitea, Forgejo, Codeberg und Gogs genannt; bei einigen könne bei Self-Hosting die Codesuche aktiviert werden

Ratschläge zur Projekt-Hosting-Strategie

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-11-29
Hacker-News-Kommentare

  • Im wohlwollendsten Sinne könnte man sagen, dass die neue GitHub-Code-Suche in der Praxis tatsächlich hervorragend ist und intern deutlich mehr leistet als eine gewöhnliche Suchmaschine, also entsprechend ressourcenintensiv sein kann
    Wenn sie auf eingeloggte Konten beschränkt wird, lassen sich erhebliche Server-Ressourcen einsparen, die sonst für das Abwehren oder Bedienen von Crawlern draufgehen würden. Der Trade-off scheint hier ungefähr zu sein: die Suchinfrastruktur 3- bis 4-mal teurer machen oder sich wegen der Login-Pflicht beschimpfen lassen. Ich habe selbst ein Code-Suchtool für GitHub-Repositories gebaut, nutze es aber kaum noch, weil die Standard-Code-Suche von GitHub so nützlich ist: https://simonwillison.net/2020/Nov/28/datasette-ripgrep/

    • Der plausibelste Grund dürfte eher sein, dass die Leute sich zwar ärgern, am Ende aber doch ein Konto erstellen und GitHub dann mit mehr neuen Nutzern prahlen kann
      Andererseits können bestehende Nutzer genervt sein, weil ohne Login nicht einmal eine Suche möglich ist. Auf fremden PCs, öffentlichen Rechnern, in Inkognito-Tabs oder mit dem Zeitaufwand für Zwei-Faktor-Authentifizierung ist das ziemlich umständlich. GitHub hätte für nicht eingeloggte Nutzer auch eine billige und schnelle Basissuche lassen können, hat sich aber dagegen entschieden
    • Die technische Begründung ist interessant, aber nicht der Kernpunkt
      Im Ergebnis kann man ohne Anmeldung bei GitHub nicht mehr an „auf GitHub gehostetem Open Source“ teilnehmen
    • Es werden viele Gründe genannt, aber wahrscheinlich wollen oder müssen sie in Wirklichkeit vor allem das Content-Scraping durch AI-Unternehmen und Forschende vermeiden
    • Falls das Absicht ist, ist Microsoft wirklich das Letzte; falls es bloße Inkompetenz ist, überrascht es nicht, dass sie sogar an so etwas Einfachem scheitern
      grep ist ein 50 Jahre altes Tool, man muss für Textsuche keinen eigenen Code schreiben und kann freie Software verwenden. Wir reden hier nicht über ein Amateur-Startup mit drei Entwicklern und einer CRUD-App, sondern über eines der größten und reichsten Tech-Unternehmen der Welt, das ohne Login nicht einmal eine ordentliche Textsuche hinbekommt. Falls es eine dritte Erklärung gibt, würde ich sie gern hören
    • Die interne Code-Suche ist einfach nur Elasticsearch, daran ist nichts Besonderes
      Die Erklärung von GitHub klingt größtenteils nach Unsinn. Für einen öffentlichen Endpunkt eine erzwungene Authentifizierung einzuführen, ist keine passende Lösung für das Problem, das sie angeblich lösen wollen. Bot-Betreiber, die an diesem Endpunkt interessiert sind, melden sich dann eben mit einem kostenlosen Konto an, also verhindert das nennenswerte Serverlast auch nicht

  • Das läuft schon seit mindestens sechs Monaten und wurde auch im Changelog angekündigt: https://github.blog/changelog/2023-06-07-code-search-now-req...
    HN-Diskussion: https://news.ycombinator.com/item?id=36230929

    • Überraschend, dass das jetzt wie eine Neuigkeit eingereicht wurde. Es fühlt sich eher wie etwas an, das es schon seit Jahren gibt, und ich kann mich kaum erinnern, wann ich zuletzt ohne Login gesucht habe
      Aus geschäftlicher Sicht ist völlig nachvollziehbar, warum sie das gemacht haben. Man macht die Leute buchstäblich zu Nutzern und steigert damit das User-Engagement

  • Man sollte GitHub jetzt nicht mehr als offene Plattform behandeln
    GitHub ist wie jeder andere Dienst ein geschlossener Walled Garden. Dass dort viele der von uns genutzten Open-Source-Projekte gehostet werden, macht es nicht besser, sondern womöglich schlimmer. Denn damit wurde geholfen, einen Teil der Beitragsinfrastruktur dieser Projekte hinter das Schloss eines Unternehmenskontos zu verlagern

    • Ob man sich bei einem „Unternehmenskonto“ anmeldet, bei irgendeiner selbst gehosteten GitLab-Instanz oder bei Bugzilla, einem Wiki und irgendetwas mit git – aus Nutzersicht ist das alles dasselbe
      Tatsächlich halte ich ein GitHub-Konto sogar für die bessere Variante. Man kann damit an fast unbegrenzt vielen Projekten teilnehmen, ohne ständig neue Konten anzulegen oder sich immer wieder neu anzumelden. Es ist schwer zu sagen, dass GitHub hier gegenüber anderen Optionen in diesem Bereich tatsächlich etwas grundlegend anders oder restriktiver gemacht hätte. GitHub hat gute Software gebaut und kostenlos angeboten, sie ziemlich offen und zugänglich gehalten, dort Standards befolgt, wo es Standards gab, und sonst APIs bereitgestellt. Außerdem stellt GitHub Open-Source-Projekten seit Langem enorme Mengen an Speicher und Rechenleistung kostenlos zur Verfügung
    • Man sollte auch erwähnen, dass GitHub dem Wachstum zahlloser Open-Source-Projekte geholfen hat
      Es gibt Git-Hosting, Wiki-Hosting, Issues, GitHub Actions, GitHub Pages und sogar eine ordentliche API. Es gibt sehr viele gute Gründe, ein Open-Source-Projekt auf GitHub zu hosten

  • 2023 hat sich das Web wirklich geschlossen. StackOverflow, Reddit, GitHub und Twitter haben alle den Scraping- und API-Zugang gebremst
    Auslöser war wohl die Kombination aus dem Versuch, AI-Training zu verhindern, und dem Druck auf die Profitabilität. Dazu kamen kommerzielle Realitäten wie die Tech-Flaute, neue Eigentümer bei Stack und X sowie Red­dits Vorstoß Richtung IPO. Langfristig dürfte ein Markt für proprietäre Daten weiter wachsen. Suchmaschinen, AI-Tools und alle anderen, die Daten brauchen, werden für Rohdatenströme oder API-Zugriff zahlen müssen, und wenn sich nur die reichsten Unternehmen diese Daten leisten können, könnte das am Ende sogar zu Kartellproblemen führen

    • Am Ende werden wohl alle es als selbstverständlich hinnehmen, dass „StackOverflow, Reddit, GitHub, Twitter“ den Zugang zu Inhalten verkaufen, die andere erstellt haben und besitzen
      Wenn etwas wirklich proprietäre Daten sind, dann sollte die Vergütung an die Eigentümer gehen, nicht an irgendeinen Betreiber eines Git-Servers. Preise und Bedingungen sollten ebenfalls von den Eigentümern festgelegt werden, nicht vom Serverbetreiber. Wenn ein Server Geld verdienen muss, kann er einfach den Basisdienst selbst bepreisen. Wenn umgekehrt jemand etwas geschaffen hat, um es zu teilen, und die Plattform damals einen effektiven Kanal für genau diese Verbreitung bot und sich selbst auch so vermarktet hat, dann ist eine nachträgliche Regeländerung moralisch gesehen Piraterie an der Arbeit dieser Person. Ein erheblicher Teil des Materials auf solchen Plattformen wäre wahrscheinlich nie hochgeladen worden, wenn die eigentlichen Eigentümer mit willkürlichen Einschränkungen und Zugangsgebühren gerechnet hätten. Wenn man die Regeln radikal neu schreiben will, sollte bestehender Content nur dann verkauft werden, wenn die Urheber ausdrücklich zugestimmt haben. Reddit hat jedoch sogar Beiträge aktiv wiederhergestellt, die Autoren massenhaft gelöscht hatten, um genau solchen Missbrauch zu verhindern
    • Dieser Trend existiert schon länger, aber in diesem Jahr ist besonders viel verriegelt worden
      https://theoatmeal.com/comics/reaching_people
    • Fairerweise muss man sagen, dass GitHub die meisten Funktionen außer der Code-Suche weiterhin über öffentliche anonyme API-Endpunkte anbietet
      Nur die Rate Limits sind deutlich strenger. Ein GitHub-Konto anzulegen ist kostenlos und vergleichsweise wenig invasiv. Auch im eingeloggten Zustand haben alle APIs ohnehin Rate Limits, damit niemand die Server lahmlegt. Deshalb haben Tools wie https://gitstar-ranking.com/ Schwierigkeiten, mit einem kostenlosen Konto die GitHub-Stars aller Repositories einzusammeln. Die eigentlich wichtigen Daten, also der Source Code, lassen sich per anonymem Clone über HTTPS abrufen, und darin kann man dann lokal suchen. Drittseiten wie https://grep.app/ funktionieren ebenfalls auf diese Weise. Bei Reddit/Twitter werden die Rohdaten selbst — also Posts, Kommentare, Upvotes und Tweets — nicht mehr per API bereitgestellt, wodurch Dritt-Tools schwer oder gar nicht mehr baubar sind. Bei GitHub sind die Rohdaten dagegen leicht zugänglich; nur die Hilfsebene der Suche ist für nicht eingeloggte Nutzer blockiert, daher ist die Lage deutlich anders
    • Das stimmt und stimmt zugleich nicht. ExpertsExchange war dafür berüchtigt, Antworten „hinter eine Mauer“ zu stellen, und war StackOverflow in gewisser Weise ähnlich
      Ich erinnere mich daran, dass StackOverflow bei seinem Start mit ExpertsExchange verglichen wurde und dennoch als „offen“ galt. Es ist jetzt Zeit, von zentralisierten Diensten zu einer stärker verteilten und mikrotransaktionsbasierten Struktur zu wechseln. Viele auf HN werden das nicht mögen, aber Q&A-Foren, News-Link- und Kommentaraggregation, Git-Hosting mit Review-Workflows sowie Wikis und Ticket-Systeme kann man vollständig dezentral umsetzen, und das sollte man auch. Techniken wie Kademlia/BitTorrent, IPFS und CryptoTokens für Mikrotransaktionszahlungen kommen dafür infrage. Nur 100% Dezentralisierung kann solche Dinge dauerhaft „offen“ halten und von Unternehmensgier frei machen. Selbst wenn Gründer mit guten Absichten anfangen, wird das Produkt langfristig immer wieder verkauft und die Kontrolle geht an die Leute aus dem Rechnungswesen über

  • Wohlwollend betrachtet erfordert Suche ziemlich viel Rechenleistung und ist deshalb ein großer Angriffsvektor für Denial of Service
    Ich weiß allerdings nicht, wie viele Verhaltensdaten GitHub von eingeloggten Nutzern sammeln kann und wie nützlich das im Vergleich zum bereits öffentlichen Code ist. Man könnte es nutzen, um herauszufinden, welche Teile des Codes wichtig sind, aber das wirkt nicht wie besonders nutzerspezifische Information

    • Das ist ein reales Problem für alle, die Suchfunktionen anbieten
      Bei meiner Suchmaschine sind nur etwa 0,5% des Traffics Menschen. Bei anderen Suchmaschinen kenne ich keine vergleichbaren Zahlen
    • Das Sammeln dieser Verhaltensdaten ist exakt die Art von Vorgehen, die man von Microsoft erwartet, daher braucht man keine wohlwollende Interpretation
      Seit der Übernahme durch MS sehe ich keinen legitimen Grund mehr, warum irgendein Open-Source-Projekt auf dieser Plattform bleiben sollte. Es fehlt auch nicht an guten Alternativen, zu denen man mit einem einzigen git clone wechseln kann
    • Ein weiterer Faktor ist, dass anonyme facettierte Regex-Suche über riesige Codebestände es Angreifern erlauben kann, nach hartkodierten Zugangsdaten zu suchen und so Zugriff auf weitere Systeme zu erlangen, ohne dass sich dabei leicht ein brauchbarer Audit-Trail erzeugen lässt
      Es gibt also mehrere nachvollziehbare Gründe, eine API zu verriegeln

  • Wenn ich nicht eingeloggt bin, nutze ich Sourcegraph. Das hat sogar den Vorteil, dass es viel besser ist als die bisherige Suche
    Es ist so einfach, dass man einfach eine Repository-URL anhängt, die mit github.com beginnt. Zum Beispiel kann man unter sourcegraph.com/github.com/rust-lang/rust/ nach unit in diesem Repository suchen

  • Ein Teil von Microsofts AI-Burggraben besteht darin, die Fähigkeit von Konkurrenten zu kontrollieren, die Informationen von GitHub zu nutzen
    Es würde mich nicht überraschen, wenn als Nächstes sogar git clone eingeschränkt würde

    • Wenn git clone eingeschränkt würde, wäre ich überrascht, wie viele CI-Systeme kaputtgingen
      Dann könnte man sich von großen Teilen von NPM, vom Go-Paketmanagement und von Jenkins-Skripten verabschieden
    • Ich frage mich, ob man Code noch als Open Source bezeichnen kann, wenn er nur hinter einem Login oder sogar hinter einem kostenpflichtigen Abo zugänglich ist
      Soweit ich mich erinnere, drosselt GitHub bereits exzessives Clonen oder API-Nutzung über Rate Limits

  • Selbst wenn man der Position der Person zustimmt, die die Frage gestellt hat, weiß ich nicht, ob man das unbedingt so sagen muss.
    Ich stimme dieser Position auch nicht vollständig zu, weil Suche keineswegs kostenlos ist und für DOS-artige Angriffe genutzt werden kann. Ich verstehe nicht, was Aussagen wie „Reicht es nicht, jede einzelne Ausscheidung zu monetarisieren, dass ihr jetzt auch noch nachverfolgen wollt, welche Codezeile ich mir ansehe?“ bringen sollen. Man sollte sich beruhigen. Auch das grundlegende Argument ist nicht besonders gut. Die Repositories selbst sind nicht hinter einem Login versteckt, öffentliche Repositories bleiben also öffentlich zugänglich, einschließlich clone. Wenn der Autor möchte, dass sein Repository und sein Code für die Allgemeinheit nützlich sind, dann müssen Beitragende ohnehin eingeloggt sein, sobald sie über bloßes Herunterladen und Suchen hinausgehen und ein Issue erstellen oder einen PR schicken.

    • Es gibt sehr häufig die Notwendigkeit, Quellcode schnell zu durchsuchen.
      Das braucht man, um herauszufinden, wie etwas funktioniert, oder wenn man etwas nicht in einem GitHub-Issue diskutiert. clone ist meist schnell, aber bei sehr großen Repositories nicht unbedingt, und möglicherweise ist auf dem aktuellen Gerät auch gar kein Platz dafür vorhanden. Wenn außerdem viele Leute statt eines Logins jedes Mal klonen, ist fraglich, ob das die Systemlast überhaupt reduziert, zumal ein GitHub-Login wegen Zwei-Faktor-Authentifizierung umständlich sein kann. Außerdem will nicht jeder ein GitHub-Konto haben.

  • HackerNews: Man kann die Startseite nicht mehr ansehen, ohne über Beschwerden zu stolpern, dass nicht eingeloggten Nutzern kein kostenloser und werbefreier Dienst bereitgestellt wird.

    • Das Sprichwort „Wenn es kostenlos ist, bist du das Produkt“ trifft in den meisten Fällen zu.
      In diesem Fall wird dein Code etwa für das Training von Copilot verwendet. Und selbst wenn das nicht so wäre und der Dienst tatsächlich so wohlmeinend wäre, wie du glaubst: Kann man wirklich Beifall dazu klatschen, dass der Dienst für ziemlich viele Nutzer schlechter wird? Ist das interessant und aufregend?
    • Gibt es Belege für diese Behauptung? Ich lese HN fast jeden Tag, aber Beiträge nach dem Muster „Ohne Login kann man X nicht machen“ wirken auf mich nicht gerade besonders beliebt.
      Das einzige Beispiel, das mir einfällt, sind die API-Änderungen bei Reddit, aber das ist schon ziemlich lange her und nur lose mit Logins verbunden.

  • Wenn du weiterhin Open-Source-Suche nutzen willst: https://sourcegraph.com/search erfordert keinen Login und umfasst auch wichtige Projekte, die nicht auf GitHub sind.
    Zur Einordnung: Ich bin CTO von Sourcegraph.

    • Ich möchte mich mit meinem privaten GitHub-Konto nicht auf einem Firmenrechner einloggen, daher nutze ich immer Sourcegraph, wenn ich Repository-Suche brauche.
      Früher hatte ich gehofft, dass die GitHub-Suche mit git clone + grep mithalten könnte, aber ich hätte nicht erwartet, dass der Preis dafür eine Login-Hürde sein würde. Soweit ich mich erinnere, war die Login-Hürde nur da, weil es sich um eine Beta-Funktion handelte, und ich hatte erwartet, dass sie verschwindet, sobald die Suche zum Standard wird.
    • Ich frage mich, warum man Suche ohne Login erlaubt, für Cody aber einen Login verlangt.