Ankündigung

Einklappen
Keine Ankündigung bisher.

Temporäre Seiten per Formulareingabe erstellen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Temporäre Seiten per Formulareingabe erstellen

    Hallo Leute,

    ähnlich wie privnote.com will ich eine Seite erstellen mit einem Textfeld welches ich befüllen und absenden kann.

    Nachdem absenden zeigt es mir einen generierten Link an. Wenn ich diesen Link aufrufe zeigt es mir die vorherige Formulareingabe an und die Seite kann nicht mich aufgerufen werden (einmaliges aufrufen sozusagen).
    Ich denk mal Privnote wird es wohl auch so machen das die "Notiz" erstmal bis zum ersten Aufruf auf einer Datenbank gespeichert wird. Ich werde das wohl auch so machen da ich sonst keinen anderen Weg kennen würde. Mir ist aber lieber dass die "Notiz" dabei verschlüsselt in der Datenbank liegt. Am liebsten würde ich das mit PGP-Verschlüsselung machen aber ich weiß nicht mal ob das so möglich ist . Naja egal!

    Ich will jetzt keine 1zu1 Lösung oder ähnliches... mir reichen paar Stichwörter und/oder Tipps!

    Wegen der Löschung nach einmaligen Aufruf habe ich noch nicht recherchiert da ich an dem Punkt mit den generierten Links stehen geblieben bin.
    vllt mithilfe von http://www.manuel-bieh.de/blog/uniqu...php-generieren ?


  • #2
    wieso pgp, bringt ja mE. nüscht viel, ne symetrische tut es doch auch, oder?
    und mysql und php haben build in function für unique id.

    löschen?
    jo mei, das findet sich dann scho.

    Kommentar


    • #3
      Was willst du denn mit einer PGP Verschlüsselung? Da kannste die E-Mails zu deiner Tante verschlüsseln aber für dein vorhaben am Ziel vorbei.

      Lass den Benutzer einen Text schreiben.
      Beim abspeichern wird dieser symetrisch verschlüsselt.
      In die Datenbank hauste ein Feld mit ner unique id random generiert (für den menschen nicht verständlich) und den verschlüsselten text.

      Dem benutzer schickst jetzt nen Link der als GET Parameter die unique id hat.
      Wenn der Benutzer die Seite aufruft, liest du erst den text aus der Tabelle aus und dann löscht du den Datensatz aus der Tabelle.

      So ist garantiert dass der benutzer das nur einmal sieht.

      Meiner Meinung nach komplett sinnlos so eine Anwendung, da es verschlüsselte E-Mails (ala PGP) genauso tut.
      "Software is like Sex, it's best if it's free." - Linus Torvalds

      Kommentar


      • #4
        Meiner Meinung nach komplett sinnlos so eine Anwendung
        Jo!

        allerdings müssen wir vor dem löschen sicherstellen, dass der user den text gelesen haben kann, also eine zeitlang, abhängig von der textlänge der text auf dem bildschirm dargestellt war.
        und das alles ohne js, denn dann kann der user ja betrügen.

        aber das kommt ja erst in teil zwei

        Kommentar


        • #5
          Musst du doch gar net
          Deshalb soll er ja erst den Select machen und dann Löschen.
          Dann hat er den Wert noch in einer Variable liegen, die er dann in ein Template einfügen kann o.ä.
          Ob da dann der Datenbankeintrag noch da ist oder nicht ist schnubs, der Benutzer bekommt den Inhalt der Variable zu sehen.

          Beim Seiten reload ist dann alles weg.
          "Software is like Sex, it's best if it's free." - Linus Torvalds

          Kommentar


          • #6
            Ob da dann der Datenbankeintrag noch da ist oder nicht ist schnubs, der Benutzer bekommt den Inhalt der Variable zu sehen.
            scho klar, wenn sein wlan nicht abraucht oder sonstwas schiefgeht.
            und wenn die nachrichten schon verschlüsslet sein müssen, sind sie sicher super wichtig; ein wiederherstellen ist jedenfalls bei deiner routine schwer möglich.
            ein sicherstellen, dass der user etwas gelesen hat (übel schwer), oder gelsen haben kann (immerhin möglich) ist wesentlich komplexer.
            deswegen hat dewr TE damit ja auch sorgen.

            Kommentar


            • #7
              Dann müsste man das vllt anhand der Session ID machen.
              Beim ersten anklicken des Links wird die Session ID des Bentuzers gespeichert zusätzlich ein TimeStamp.
              Verliert er jetzt die Internetverbindungen oder wird die Seite nicht fertig geladen etc. dann kann der Benutzer die Seite neu laden.
              Jetzt wird überprüft ob die Session id noch gleich ist und der Timestamp nicht älter als 10 Minunten (pauschal gesagt) ist. Ist dies so kann er die Seite nocheinmal anschauen, aber die Session ID wird dann direkt noch regeneriert, bzw. der eintrag gelöscht.
              "Software is like Sex, it's best if it's free." - Linus Torvalds

              Kommentar


              • #8
                Wenn aber der browser abstürzt kannst gar nichts machen.
                Da gibts keine 100%ige Möglichkeit.
                "Software is like Sex, it's best if it's free." - Linus Torvalds

                Kommentar


                • #9
                  Verliert er jetzt die Internetverbindungen oder wird die Seite nicht fertig geladen etc. dann kann der Benutzer die Seite neu laden.
                  man kann ja rausfinden ob und wie die http verbindung beendet wurde ( ich weiss http 1.1 ) aber das lassen wir mal aussen vor.
                  neulanden wiederspriecht der idee des einmaligen ladens jedenfalls; und die daten sind sensibel.

                  wenn der rechner abrauchst, ja dann kriegt der schurkenstaat halt keine superbome; da geb ich dir recht.
                  möglicherweise fällt dem TE ja noch was ein...

                  Kommentar


                  • #10
                    Genau machen wir doch eine Master-Arbeit draus

                    - Dann muss man halt am Ende der Nachricht klicken "Gelesen" und weg ist die.

                    oder

                    - Man kann die nach erstmaligen "requesten" nur noch zB 2 Minuten nochmals requesten, also wenn der Browser offen bleibt kann man die eine Std auch lesen, aber wenns zB beim Öffnen verreckt und man ist schnell genug (hier 2 MInuten), dann hat mein eine 2. Chance.

                    etc..
                    Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                    PHP.de Wissenssammlung | Kein Support per PN

                    Kommentar


                    • #11
                      Freute mich sehr dass ihr euch so rege beteiligt Vielen Dank!

                      Wie JaMa beim Post #5 schon beschrieben hat reicht es mir aber dennoch Danke dass ihr euch darüber Gedanken gemacht habts!

                      Ich hab es nun jetzt soweit hingebracht dass man eine Nachricht erstellt und diese mit php uniqid einen eben einzigartige ID zugewiesen bekommt.
                      Alles natürlich in der Db eingepflegt und nach dem Submit wird mir der Link angezeigt wo ich die Nachricht sehen kann.

                      Das es nun gelöscht wird nach einmaligen Aufruf mach ich heute noch. Außerdem soll es nach einer gewissen Zeit ohne Aufruf auch gelöscht werden aber dass schau ich mir noch an.

                      Was noch fehlt ist die Verschlüsselung der Nachricht in der Datenbank. Da habe ich unter "symetrisch verschlüsselung" folgendes gefunden: http://staticfloat.com/php-programmi...selung-in-php/
                      Ist das in Ordnung und brauchbar? Da ich mit Verschlüsselungen bislang nicht viel zu tun hatte wollte ich euch fragen was der große Unterschied zwischen symetrischen und asymetrischen Verschlüsselungen ist... ist das eine sicherer als das andere?

                      Danke Leute!

                      Kommentar


                      • #12
                        Die Unique ID darf aber nicht nur 1,2,3,4, ... sein, sonst könnte jemand einfach die ID's durchprobieren.

                        Für das Löschen müsstest du einen Cronjob anlegen der ein PHP Script startet, welcher alle Einträge die älter als die von dir gesetzte Zeit sind löscht.

                        Ja, du kannst MCrypt nehmen, ist direkt in PHP implementiert und du kannst verschieden Algorithmen verwenden (z.B. AES 256).
                        Sicher ist es auch solange niemand den Schlüssel rausfindet.

                        Man kann symetrische und asymetrische Verschlüsselung nicht richtig miteinander im Bezug auf Sicherheit vergleichen, da beide unterschiedlich konzipiert sind.
                        Einfach gesagt hast du bei einer symetrischen Verschlüsselung einen Schlüssel, mit dem man Verschlüsseln und Entschlüsseln kann.
                        Bei der Asymetrischen Verschlüsselung gibt es einen public key mit dem Verschlüsselt wird und einen private key mit dem entschlüsselt wird.

                        SSL z.B. ist eine Kombination aus Asymetrischer und Symentrischer Verschlüsselung.
                        "Software is like Sex, it's best if it's free." - Linus Torvalds

                        Kommentar


                        • #13
                          Ist das in Ordnung und brauchbar? Da ich mit Verschlüsselungen bislang nicht viel zu tun hatte wollte ich euch fragen was der große Unterschied zwischen symetrischen und asymetrischen Verschlüsselungen ist... ist das eine sicherer als das andere?
                          dein artikel ist von 2011, was kein ko kriterium ist, aber mal erwähnenswert.
                          der link zur docu ist sicher besser:
                          http://php.net/manual/de/book.mcrypt.php

                          zudem wurde das hier schon x mal durchgekaut.

                          a-/symetrisch:
                          das findest du selbst raus.

                          //scheiss mieser cache:
                          hab dein beitrag nicht gesehen JaMa

                          Kommentar


                          • #14
                            Zitat von JaMa
                            Für das Löschen müsstest du einen Cronjob anlegen der ein PHP Script startet, welcher alle Einträge die älter als die von dir gesetzte Zeit sind löscht.
                            Alternativ bei jedem "normalen" Lösch-Request das auch gleich prüfen lassen, je nachdem wie oft deine Seite besucht wird oder wie heiß die Infos sind, kann das auch ausreichend sein. Das kann ein Nachteil sein, aber auch den Vorteil das du den CronJ. nicht brauchst.
                            Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
                            PHP.de Wissenssammlung | Kein Support per PN

                            Kommentar


                            • #15
                              Zitat von hausl Beitrag anzeigen

                              Alternativ bei jedem "normalen" Lösch-Request das auch gleich prüfen lassen, je nachdem wie oft deine Seite besucht wird oder wie heiß die Infos sind, kann das auch ausreichend sein. Das kann ein Nachteil sein, aber auch den Vorteil das du den CronJ. nicht brauchst.
                              moma

                              Ich bin einfach zu gütig

                              Das mit dem Cache stört mich auch immens.

                              hausl

                              Niemals.
                              Das ist ein Background Task und hat nichts mit einer Benutzerinteraktion zu tun.
                              Erzeugt unnötig lange Ladezeiten und eine unnötige Serverauslastung.
                              Das geht gut wenn die Seite kaum aufrufe hat. Stell dir vor die Seite generiert am Tag 300.000 aufrufe, dann weißt du dass 300.000 mal am Tag die Datenbank nach Einträgen durchsucht.
                              "Software is like Sex, it's best if it's free." - Linus Torvalds

                              Kommentar

                              Lädt...
                              X