|
|
|
|
Klar wenn man eine app hat wo eh ein user login mit verbunden ist dann ist es simple. Aber nehmen wir mal an das die app vom spiegel.de seine Daten aus einer API holt die nicht unauthentifiziert zugreifbar ist. Dann muss da ja eine art hartgecodeter token oder ähnliches drin sein.
Ich dachte ob es vielleicht sowas gibt das bei iOS/Android es eine spezielle Methode gibt wo eine verschlüsselte APP-ID oder sowas mitgeschickt wird und dieser dann der Token wäre..
Wie gesagt, das ist nur was mir letztens im Kopf durchging...
|
|
|
|
|
|
|
Entweder die API braucht eine Authentifizierung - dann braucht auch die App eine - oder sie braucht halt keine, dann braucht auch die App keine.
|
|
|
|
|
|
|
App macht oauth mit dem User, api bekommt jwt signiert vom idp . Weniger ist nicht angemessen.
|
|
|
|
|
|
|
Definiere "mit dem User" bei einer App ohne User login.
|
|
|
|
|
|
|
| Zitat von X-Tender
Definiere "mit dem User" bei einer App ohne User login.
| |
Das ist doch der Punkt. Es muss einen Login* geben, wenn die API eine Authentifizierung erfordert.
*Oder irgendwelche Wegwerftokens oder was auch immer.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Ameisenfutter am 24.02.2022 18:37]
|
|
|
|
|
|
Vielleicht machst du mal konkret, worauf Du eigentlich hinaus willst.
|
|
|
|
|
|
|
Noch konkreter geht nicht
Das war eine Frage ob es sowas gib. Authentifizierung mit einer API ohne das ein User login drin ist. Ob sich da überhaupt lohnt einen Token in die App hart zu coden oder gleich offen zu lassen.
Ich kenne mich nicht so aus was app Entwicklung angeht. Vielleicht gibt es da was.
|
|
|
|
|
|
|
Es hat halt etwas von einem Henne-Ei-Problem. Eine API soll nur nach Authentifizierung aufrufbar sein. Gut, also muss man irgendwie seine Credentials hinschicken, sei es ein hard-coded Login mit BasicAuth, der public-part eines SSH keys oder ein PGP-Key der in einer Chain recognized wird. In allen diesen Beispielen liegt im Falle einer Smartphone App, bei jedem User der Schlüssel lokal am Device. Und den kannst du noch so tief im Code vergraben, der Schlüssel ist irgendwo auslesbar.
Warum nicht diesen Schlüssel gesichert ablegen? Nunja, hier beißt sich dann die Katze in den Schwangs: selbes Problem wie vorher, nur andere Stelle.
|
|
|
|
|
|
|
Nichts. Hart. Coden.
|
|
|
|
|
|
|
Ok, bei IOT werden schon mal private keys auf die Geräte geladen, aber jedes Gerät hat einen individuellen Key. Wenn man den extrahiert bekommt, kann man sich als das Gerät ausgeben. Einige Geräte werden aber auch über eine App gekoppelt, wo wieder ein User langlebige tokens generieren und aufs Gerät laden kann.
Sowas macht man aber eben nur mit Geräten ohne Bildschirm.
|
|
|
|
|
|
|
Oder mal ganz untechnisch:
Credentials gehören nur in vertrauensvolle Hände. Wenn der Endnutzer nicht vertrausvoll für diese Credentials ist, haben sie in einer App für den Endnutzer nichts zu suchen.
|
|
|
|
|
|
|
Gut danke. Das man Credentials nicht hart coded ist selbsterklärend, wie schon paar mal gesagt, wollte nur mal lauschen ob es für dieses "Henne-Ei" Problem eine Lösung gibt bei Apps, aber anscheinend nicht.
Thread kann zu.
|
|
|
|
|
|
|
| Zitat von Admiral Bohm
Ok, bei IOT werden schon mal private keys auf die Geräte geladen, aber jedes Gerät hat einen individuellen Key. Wenn man den extrahiert bekommt, kann man sich als das Gerät ausgeben. Einige Geräte werden aber auch über eine App gekoppelt, wo wieder ein User langlebige tokens generieren und aufs Gerät laden kann.
Sowas macht man aber eben nur mit Geräten ohne Bildschirm.
| |
TPM TPM TPM. Also wenn schon.
Einfach in's Binary packen: Lieber nicht. Bildschirm oder nicht ist auch relativ wurscht, user input is where it's at.
|
|
|
|
|
|
|
| Zitat von wuSel
Nichts. Hart. Coden.
| | sbi.gif
|
|
|
|
|
|
|
|
|
|
|
Haha.
|
|
|
|
|
|
|
Ja komm
|
|
|
|
|
|
|
| Zitat von SwissBushIndian
Ja komm
| |
Dafür muss man aber schon hart coden
|
|
|
|
|
|
|
Hat hier jemand Erfahrung mit "Live Coding" Sessions während eines Bewerbungsgesprächs? Hab demnächst eins für ne Firma hier aus der Region. Ist das schon so üblich in DE? Oder kann ich mich auf nen sehr amerikanischen Interviewstil einstellen bei dem ich irgendwelche Algorithmen händisch nachprogrammieren soll?
/edit: Das ganze Interview ist remote, falls relevant
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von NI-Xpert am 03.03.2022 15:49]
|
|
|
|
|
|
Hab ich ja noch nie gehört.
|
|
|
|
|
|
|
Dito, da würd ich ja nie einen Job kriegen.
|
|
|
|
|
|
|
Wenn stack overflow und das Intelforum verboten sind, dann gute Nacht
|
|
|
|
|
|
|
Einfach hoffen, dass in VSCode oder so die AI-unterstützte Programmierung aktiv ist.
|
|
|
|
|
|
|
|
|
|
|
| Zitat von NI-Xpert
Hat hier jemand Erfahrung mit "Live Coding" Sessions während eines Bewerbungsgesprächs? Hab demnächst eins für ne Firma hier aus der Region. Ist das schon so üblich in DE? Oder kann ich mich auf nen sehr amerikanischen Interviewstil einstellen bei dem ich irgendwelche Algorithmen händisch nachprogrammieren soll?
/edit: Das ganze Interview ist remote, falls relevant
| |
Einmal gemacht. In einem fucking Word Dokument. Ohne Ctrl+space kann ich nix.
|
|
|
|
|
|
|
Wow. Die haben dir nicht einmal eine IDE gegeben?
|
|
|
|
|
|
|
tl;dr bist abhängig davon wie Kompetent dein Ggü ist.
Et steht und fällt einfach mit dem der die Session führt und wie.
Der Optimalfall ist einfach eine Erprobung deiner Fähigkeit Lösungsorientiert zu arbeiten - da geht es nicht darum dass du integration Details und Syntax kannst, sondern wie Methodisch du vorgehst - das ist natürlich in Fall von einer Livecodingsession etwas gekuppelter, aber letzten Endes kein Beinbruch wenn du holprig bist weil du nicht mit deiner gewohnten IDE arbeitest. Googlen solltest du dürfen, ansonsten sind das irgendwelche affektierten Buzzwordpimmel die sich nur geil fühlen wollen.
Ich erwähne meistens dass Google ausdrücklich erlaubt ist, Rückfragen an uns zu integration details erlauben wir auch.
Der andere Fall wäre, wenn du dich auf eine ganz bestimmte Domain mit einem ganz spezifischen Stack bewirbst für ein konkretes Projekt und der Problembereich klar aus der Rolle hervorgeht, da wirst du sicher trotz Notepad eine integration hinrotzen müssen - aber ich glaube das wäre dir vorher bewusst und für mich klingt das nicht danach :0)
/e: Wir selbst machen das aber zugegeben nur für junior Stellen, meine Erwartungshaltung ist da also nie ein flawless af code skiller.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Tenz am 03.03.2022 16:57]
|
|
|
|
|
|
Selber nie gemacht, wir stellen den Kandidaten lieber eine Testaufgabe die er in seiner gewünschten Zeit und Sprache lösen kann, die besprechen wir dann entspannt.
Aber von Kollegen mal mitbekommen. War Scheiße, weil beschissen organisiert von externen Leuten, die echt grenzwertig arg ihren Job verfehlt haben.
Richtung Frontend war es sowas wie "Schreibe ohne Libraries in Javascript eine Methode, die die Wörter eines Satzes umdreht.", "Schreibe einen Markdown-Parser." und noch was, was ich vergessen habe.
|
|
|
|
|
|
|
Sollte mal bei nem gespräch irgend n algorithmus mit bleistift auf papier coden.
Es war nicht gut, auch der rest vom gespräch eher merkwürdig.
Habe dann das bewerbungsverfahren mit lolnope beendet.
|
|
|
|
|
|
|
Lölchen!
Live coding hab ich auch schon paar mal gehört, ist mir aber noch nicht untergekommen.
Hab letztens mal wieder ein Bewerbungsverfahren durchlaufen (neuer Job ab 01.04., whoop whoop) und musste da auch ne Aufgabe machen.
Aber super entspannt - konnte die angehen wie ich will, Stack frei wählbar, kein Zeitlimit - super sweet.
Hatte vor einem Jahr mal eine machen müssen, die richtig eklig war.
Musste son Stoppuhr-Timer Scheiss bauen und hatte für die Umsetzung auch noch ein Zeitlimit.
Schon fies die potentiellen Kandidaten mit Javascripts Zeit API zu quälen.
|
|
|
|
|
|
Thema: Software-Entwicklung 1 ( Nach log4j ist nichts mehr wie es war ) |