Beiträge von cottton

    Tnx für die Beiträge.

    also vorsichtig bin ich ja. Teilweise paranoid =)
    Kann man also davon ausgehen, dass Apps vom Play Store geprüft sind?

    Btw: konnte ich nicht schreiben, weil ich mitm Phone echt Probleme hab (endlich wieder ne richtige Tatatur unter die Finger!!! :D)
    Anstoß war ein Beitrag im Fernsehn. Ein Typ wurde abgezockt: die SMS-Tan kam aufs Phone, aber die Buchung (nach Ungarn o.ä,) war schon durch.
    (dazu das Thema Trojan aufm Smartphone/SMS-Weiterleitung/Ersatzkarte ...)

    Und ich hatte auch Seltsame Erfahrungen vor rund nem Monat gemacht:
    -> via SofortÜberweisung wollte ich was kaufen. Da ich aber wie gesagt manchmal paranoid bin, gebe ich gerne mal ein falsches PW ein.
    Und siehe da - ich hab von der Bank ne SMS-Tan bekommen!
    Die Bank hat mir dann noch freudlicher Weise (nicht sarcasm=) mitgeteilt, dass solche Geschäfte gegen deren Bedingungen sind. (man muss bei SofortÜberweisung die Logindaten eingeben. Die lösen dann die Überweisung aus.)
    Was nu aber komisch war: die Logs der Bank sahen korrekt aus.
    Am Ende gibts halt nur 3 Möglichkeiten:
    - ich hab doch das richtige PW eingegeben (:D ausgeschlossen, denn so dumm bin ich nicht)
    - die Bank hat das falsche PW akzeptiert (demnach wären die Logs auch korrekt mitgeschrieben)
    - SofortÜberweisung hat mein PW gechached/gespeichert und gegen das falsche abgesendete ausgewechselt (... :D erm ... könn wir dann glaub ich auch knicken)

    Nachstellen konnte ich es am gleichen Tag nicht mehr. Danach auch nicht mehr versucht.

    Und was ist die frage? :D

    Wegen Responsive:
    Du willst sicher mit media queries arbeiten.
    Ich bin zwar fuer responsive desings, allerdings gegen uebermaessigen gebrauch von media queries.
    (und gegen kacke Notebooktastaturen :D)

    Ohne schnickschnak wuerde ich es so aufbauen, dass:
    #artikel_links
    width 50%
    text-align right

    #artikel_rechts
    width 50%
    text-align left

    Dadurch solltes Du das gewuenschte Ergebnis bekommen und der Browser kuemmert sich.
    soll heissen: wenn Fenster zu klein, dann knallt das rechte Element nach unten.

    EDIT: die beiden Artikel muessen wohl noch in einem (zB) div liegen, welches auf 100% Breite alleine steht

    okiedokie :D
    hab versucht alles so einfach wie möglich in den comments zu erklären:

    Durch die Beziehung (FOREIGN KEY) ist es jetzt nicht möglich zB eine `id_texte` mit dem Wert 2 in die Tabelle `md5` einzufügen, wenn in der Tabelle `texte` nicht auch eine `id` mit dem Wert 2 existiert.

    Kurz und einfach:
    Inhalt Tabelle `texte`

    Code
    id | text
    -----------------------
    1  | mein text ...
    2  | auch ein text ...

    Inhalt Tabelle `md5`


    INSERT:

    UPDATE:

    DELETE:

    SELECT:

    Da geht bestimmt noch was, aber das Modell an sich sollte funktionieren.

    Dann wäre es evtl sinnvoll 2 tbl abzulegen.
    tbl_texte:
    `id`-- primary key
    `text`

    tbl_md5:
    `id_texte` -- fremdschlüssel (foreign key) von tbl_texte
    `md5` -- unique index

    Durch den Fremdschlüssel stehen die beiden Tabellen in Beziehung und es kann nur eine in tbl_texte existierende `id` in tbl_md5 eingefügt werden.
    Wenn Du also nur prüfen willst, ob ein Text schon existiert, dann suchst Du in der "schnellen" Tabelle `tbl_md5` nach dem md5 Hash.
    Natürlich holst Du Dir dabei auch gleich die `id`, um bei Bedarf den Text aus `tbl_texte` via `id` zu lesen.

    Musste Du aber abwiegen. Denn ein Insert wird dann über 2 Tabellen laufen (Stichworte "BEGIN TRANSACTION", "COMMIT", "ROLLBACK").
    Wäre halt mMn für sehr viele Datensätze angebracht.

    btw: gerade drüber gestolpert: http://stackoverflow.com/questions/9245…-select-results
    (als vorschau ect evtl)


    EDIT:
    ach da fällt mir gleich wieder so viel ein .. :D
    Du kannst für INSERTs auch einen Trigger erstellen:

    SQL
    CREATE TRIGGER 'triggername' 
    AFTER INSERT ON `tbl_texte` 
    FOR EACH ROW 
        INSERT INTO `tbl_md5` 
        SET `id` = NEW.`id`, `md5` = md5(NEW.`text`);


    Also wird bei jedem INSERT INTO `tbl_texte` der md5 und die id in `tbl_md5` geschickt =)
    (wenn man trigger mag)

    naja, dann wäre der riesen Text wieder an den Sql-Server geschickt.
    Dann evtl doch den md5 via PHP berechnen.


    Die md5 dann immer per PHP erstellen.
    BTW: eigtl brauchst Du gar keine id, da der md5 ja unique sein sollte/muss - md5 könnte also auch primary key sein.
    ABER es soll wohl sinnvoller sein den fortlaufende numerische ids zu verwenden anstatt lange Strings. Kommt aber auch wieder auf die Masse an Daten an.

    ungetestet und nie versucht, aber:
    Kommt drauf an wie groß/lang der Text ist.
    Wenn Dein Text mehrere hundert Zeichen lang sein kann und Du nach dem gesamten Text suchen musst, dann wäre es eine komische query an den Sql-Server

    SQL
    ...
    WHERE `text` = '....mal ein riesen langer text angenommen ...'


    Dann würde es wohl wirklich Sinn machen ne Prüfsumme von dem zu speichernden Text gleich mit zu speichern.
    In etwa:
    tbl_texte:
    `id`-- primary key
    `text`
    `md5` -- unique index

    md5 also index, damit Du nicht die ewig langen Texte indexieren musst (was bissl blöd wäre =)
    unique index, damit Du keine doppelten Texte speichern kannst.
    Den md5 kannst Du auch gleich dem Sql-Server überlassen:

    SQL
    INSERT INTO `tbl_texte`
    (`text`,`md5`)
    VALUES (:text,md5(:text))


    Dann bekommst Du ein Feedback, ob der gleiche Text schon vorhanden war.
    Spart eine vorangehende Such-Query.

    indeed.
    sysop lies Dir mal das hier Durch: Loginpasswort richtig hashen - password_hash() & password_verify()
    und auf der letzten Seite im Post von The Scout erwäht: http://www.martinstoeckli.ch/hash/de/
    Wie The Scout schon sagte - du hast da was falsch verstanden.

    Und ja - man MUSS davon ausgehen, dass jemand mal an die Sql tables kommt. Denn man will als Verantwortlicher selbst mit runtergelassenen Hosen noch sicher auf dem Boden stehen.

    btw: jemand mitbekommen? http://www.heise.de/newsticker/mel…rt-2156965.html (http://www.chip.de/artikel/Mitteilung_68834577.html)

    Also gelernt hab ich, dass eine Collation mit der Endung _ci case insensitive ist.
    Demnach sehe ich utf8_bin für case sensitive an.
    Allerdings bei mir getestet (MySQL Version: 5.6.14) bekomme ich bei utf8_bin kein case sensitive (also egal ob groß oder klein)

    Versuch mal 'utf8_general_ci'

    SQL
    ALTER SCHEMA `tbl_name` 
    DEFAULT COLLATE 'utf8_general_ci';

    Naja, SESSIONS sind mMn schön einfach für Admin-Seiten.
    Ich bin immer davon ausgegangen, dass die SESSION auch wirklich weg is, wenn der Browser zu ist.
    Und via .ini kann man die lifetime setzen - also schön zu gebrauchen für eine AdmSession.

    In vielen Fällen würde das jetzt heißen:
    - admin schließt Browser
    - fremder geht an den PC/... und öffnet Browser und hat die AdmSession -.-

    wolf
    dann muss aber JS aktiviert sein =(

    Bei einer erstellten SESSION erwartet man ja, dass beim Schließen des Browser diese verfällt.
    ... nix da bei Chrome.
    Ich dachte gerade bei meinem Loginscript "warum bin ich immer noch eingeloggt?" ...
    tja ... umsonst im Code gesucht ... Chrome is schlud.

    Seit 2012 nicht gefixt? -.-
    https://code.google.com/p/chromium/issues/detail?id=128513
    EDIT:

    Zitat

    Status: WontFix

    :thumbdown:
    Jetz frag ich mich, wie ich die SESSION beim Schließen des Browsers löschen kann.