| | | | |
| |||||||
| Datenbanken SQL und Co |
|
| | LinkBack | Themen-Optionen | Thema bewerten |
| | |
| PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten | |
| | |
| Erfahrener Benutzer Registriert seit: 01.09.2010
Beiträge: 4.561
PHP-Kenntnisse: Fortgeschritten ![]() ![]() ![]() | dann ist es offensichtlich, dass dein Blowfish wohl selbst Hochkomma produziert, die vorzeitig den String beenden für mysql würde ich dir zu mysql_real_escape_string raten bei mssql muss man selbst Hand anlegen oder aber mit prepared Statements (über eine andere Datenbankerweiterung) arbeiten PHP-Code:
__________________ "Irren ist männlich", sprach der Igel und stieg von der Drahtbürste |
| | |
| | |
| Neuer Benutzer Registriert seit: 03.01.2012
Beiträge: 6
PHP-Kenntnisse: Fortgeschritten ![]() | Danke eagle, dass das Blowfish Hochkomma und Backslashes/Slashes produziert ist und der String vorzeitig beendet wird war mir schon klar gewesen, ist in meinem ursprünglichen Text leider nicht ganz ersichtlich. Allerdings hatte ich nicht an die einfache und logische Lösung des replacen der Inhalte gedacht. Wenn ich stripslashes verwenden würde, wäre aber der Blowfish Code zerstört - das muss ja auch wieder decrypted werden, habs nun aber für die relevanten Zeichen händisch gemacht und es funktioniert einwandfrei. Mein Encrypt von HTML > Blowfish > str_replace > MSSQL varchar: PHP-Code: PHP-Code: |
| | |
| | |
| Erfahrener Benutzer Registriert seit: 10.10.2009
Beiträge: 2.629
PHP-Kenntnisse: Fortgeschritten ![]() ![]() ![]() ![]() ![]() ![]() | Kannst du den Blowfish Code nicht noch einfach durch Base64 jagen? Spart dir das Replacen.
__________________ "Alles im Universum funktioniert, wenn du nur weißt wie du es anwenden musst". |
| | |
| | |
| Erfahrener Benutzer Registriert seit: 19.06.2009
Beiträge: 837
PHP-Kenntnisse: Fortgeschritten ![]() ![]() ![]() ![]() ![]() | Da hast Du Dich jetzt aber für die idiotischste Lösung entschieden. Was machst Du, falls Dein Input mal zufällig DBLUP enthält? Mit Deiner Decodierung zerschießt Du Dir da die Daten. Abgesehen davon werden Single-Quotes bei MsSQL gewöhnlich durch zwei aufeinander folgende Quotes maskiert. Ein weiteres Problem hast Du noch: Von der mssql-Extension ist heutzutage auch weitest gehend abzuraten. Microsoft selbst hat mit sqlserv was neues raus, was sich besser eignet. Alternativ kommt auch PDO in Frage - das kann Prepared Statements und macht Dir auch für Binärdaten das Leben erheblich leichter. Z(Zu Binärdaten sagt Microsoft selbst übrigens kurz und knapp "nicht mit reinem SQL - nimm Prepared Statements für sowas.". Gruß Jens |
| | |
| | |
| Neuer Benutzer Registriert seit: 03.01.2012
Beiträge: 6
PHP-Kenntnisse: Fortgeschritten ![]() | @Dark_Guardian: Das war des Rätsels Lösung, soetwas schwebte mir von Anfang an vor, hatte davon aber noch nicht gehört. @Jens: danke man lernt nie aus *idiot*, warum ist von der mssql-Extension abzuraten, kannst du dies bitte spezifizieren? Soweit ich gesehen habe, bleibt damit die Syntax weitgehend gleich (es gibt nur zb. kein sqlsrv_fetch_assoc , aber mit _array hat man ja quasi das selbe). Mssql wird von MS nicht mehr weiter unterstützt, womit ich annehme, dass in künftigen Serverversionen nur die sqlserv Extension von Anfang an einwandfrei laufen wird. Hier läuft aber 2003 und MSSQL2000 und dies wird sich auf Kundenseite nicht ändern. |
| | |
| | |
| Erfahrener Benutzer Registriert seit: 01.09.2010
Beiträge: 4.561
PHP-Kenntnisse: Fortgeschritten ![]() ![]() ![]() | das hat weniger mit der "Serverversion" zu tun, sondern mit PHP selbst sowohl die mysql als auch die mssql-Erweiterung gehören definitiv zum GANZ alten Eisen und werden möglicherweise mit einer folgenden PHP-Version nicht mehr ausgeliefert / verfügbar sein. Die Folge wäre das dein Hoster irgendwann beschließt seine Webserver auf neue Software-Versionen umzustellen und dein Script dann "knallt" weil die Datenbankschnittstelle nicht mehr funktioniert und du dir dann unter erschwerten Bedingungen DANN eine neue Datenbankschnittstelle basteln musst. Daher wäre es günstiger JETZT schon auf die zukunftssichere PDO-Erweiterung zu setzen, die als neuer PHP-Standard wohl nicht so schnell ausgewechselt wird Obendrein bietet sie mit prepared Statements ein zeitgemäßes Mittel um sämtliche Escaping-Probleme samt SQL-Injections gleich an der Wurzel zu packen bzw gleich ganz zu verhindern
__________________ "Irren ist männlich", sprach der Igel und stieg von der Drahtbürste |
| | |
| | |
| Neuer Benutzer Registriert seit: 03.01.2012
Beiträge: 6
PHP-Kenntnisse: Fortgeschritten ![]() | Lt. MSDN: The SQLSRV driver does not support SQL Server 2000 Somit bleiben wir bei dem ganz alten Eisen, da dies die Voraussetzungen des Kunden sind (und lt. deren IT so bleibt, da es keinen "Hoster" gibt, sondern die eine eigene Serverfarm unterhalten). PDO inkl. prepared Statements werd ich mir aber generell mal anschaun für die künftigen Projekte, danke. |
| | |
|
| Themen-Optionen | |
| Thema bewerten | |
|
|
| Besucher kamen über folgende Suchanfragen bei Google auf diese Seite |
| line 1: incorrect syntax near \'max\', verschlüsselung php java blowfish, blowfish in varchar2 speichern, mssql function blowfish encryption, mssql blowfish function, blowfish utf-8, php mcrypt_encrypt anführungszeichen, php blowfish verschlüsselung, blowfisch in datenbank speichern, msdn mssql blowfish, blowfish updaten, blowfish verschlüsselung zeichen art, mssql snglup, php mssql unclosed quotation marks |