hier ein kleines Script das heute nebenbei entstanden ist, dachte mir das könnte für einige Leute nützlich sein. Hiermit könnt ihr phpmyadmin in das Oxid Backend integrieren (ohne doppel Anmeldung).
Nachdem Ihr die Dateien erstellt habt müsst ihr das phpMyAdmin Paket vom Hersteller herunterladen und in den admin Ordner laden als [B]/admin/phpMyAdmin/[/B] (großes M großes A).
Jetzt muss nur noch der single sign on aktiviert werden damit das ganze funktioniert, öffnet dazu im /admin/phpMyAdmin/ Ordner die Datei config.inc.php (erstellt diese falls Sie nicht existiert):
<?php
/* vim: set expandtab sw=4 ts=4 sts=4: */
/**
* phpMyAdmin sample configuration, you can use it as base for
* manual configuration. For easier setup you can use setup/
*
* All directives are explained in Documentation.html and on phpMyAdmin
* wiki <http://wiki.phpmyadmin.net>.
*
* @version $Id$
* @package phpMyAdmin
*/
/*
* This is needed for cookie based authentication to encrypt password in
* cookie
*/
$cfg['blowfish_secret'] = ''; /* YOU MUST FILL IN THIS FOR COOKIE AUTH! */
/*
* Servers configuration
*/
$i = 0;
/*
* First server
*/
$i++;
/* Authentication type */
$cfg['Servers'][$i]['auth_type'] = 'signon';
$cfg['Servers'][$i]['SignonSession'] = 'admin_sid';
$cfg['Servers'][$i]['SignonURL'] = '/admin/index.php';
$cfg['Servers'][$i]['extension'] = 'mysql';
$cfg['Servers'][$i]['connect_type'] = 'tcp';
$cfg['Servers'][$i]['compress'] = false;
/* Select mysqli if your server has it */
$cfg['Servers'][$i]['AllowNoPassword'] = false;
/* rajk - for blobstreaming */
$cfg['Servers'][$i]['bs_garbage_threshold'] = 50;
$cfg['Servers'][$i]['bs_repository_threshold'] = '32M';
$cfg['Servers'][$i]['bs_temp_blob_timeout'] = 600;
$cfg['Servers'][$i]['bs_temp_log_threshold'] = '32M';
/*
* Directories for saving/loading files from server
*/
$cfg['UploadDir'] = '';
$cfg['SaveDir'] = '';
?>
Nun nur noch den tmp Ordner leeren und Ihr solltet im Service Menü einen neuen Punkt “phpMyAdmin” haben. Viel spaß damit!
wenn ich mit dem Firefox im Backend bin, dann wirft mich der Aufruf des Menüpunktes phpMyAdmin zurück auf die Anmeldemaske zum Backend. Aber komplett, inklusive Session abmelden…
Kann das jemand verifizieren? Oder liegt das an mir?
Ein Kollege hat mich gerade darauf hingewiesen dass es in diesem Fall hilft den tmp zu leeren. Woran es liegt wissen wir auch schon, und zwar passiert das immer wenn man sich nicht explizit im phpmyadmin screen ausloggt bevor man sich aus dem admin screen ausloggt. Da muss wohl noch ein kleines Modul her um bei admin logout auch die pma session zu killen - irgend jemand lust das hinzuzufügen ?
Hallo Aggrosoft (und alle anderen),
Nettes Modul, hat vielleicht schon jemand den Logout-prozess für pma hinzugefügt, so dass man es nutzen kann ohne jedes Mal den tmp-Ordner zu leeren?
nette Idee, aber wenn man eine derartige Software in den Shop einbindet dann schafft man auch eine sehr mächtige Sicherheitslücke
Heise ist voll mit Hinweisen zu kritischen Lücken.
Wenn man das implementiert dann sollte auch eine richtige Update Funktion dabei sein. Diese Software veraltet sonst und Hacker bedanken sich, sie kommen dann einfach an die Kundendaten.
Oxid fixt Security Bugs mit Updates für den Shop - eine veraltete phpmyadmin Version -an die man nie oder sehr selten denkt- öffnet den Shop. Ich muss daher abraten dies zu nutzen, oder im eigenen Update Protokoll zu vermerken - damit die Software nicht vergessen wird.
in aller Regel wird phpMyAdmin vom ISP bereitgestellt und gepflegt - wer seinen (Root)Server selbst wartet, muss natürlich im Rahmen der regelmäßigen Updates auch das abprüfen
Außerdem - diese nette kleine Tool lädt nur die phpMyAdmin-Oberfläche in den Hauptframe im Adminbereich, eine tiefere Verknüpfung findet nicht statt, zusätzliche Sicherheitsrisiken werden nicht geschaffen.
[QUOTE=Hebsacker;97895]in aller Regel wird phpMyAdmin vom ISP bereitgestellt und gepflegt - wer seinen (Root)Server selbst wartet, muss natürlich im Rahmen der regelmäßigen Updates auch das abprüfen
Außerdem - diese nette kleine Tool lädt nur die phpMyAdmin-Oberfläche in den Hauptframe im Adminbereich, eine tiefere Verknüpfung findet nicht statt, zusätzliche Sicherheitsrisiken werden nicht geschaffen.[/QUOTE]
Hallo Ray,
es handelt sich hier aber nicht um ein phpmyadmin vom ISP / Hoster, was von diesen anständig gepflegt wird.
Das Script liegt im Adminbereich vom Shop
$sUrl .= "admin/phpMyAdmin/index.php";
die Pflege durch den Shopbetreiber kann nicht sichergestellt werden, der hat mit dem normalen Geschäft genug zu tun.
Bei einem Shop Update durch einen Dienstleister erfolgt auch kein Update von phpmyadmin bzw. sicher nicht ständig.
Wir empfehlen aus Gründen der Sicherheit jedem Shopbetreiber das er seinen Adminbereich
-die-shop-url.TLD/[B]admin[/B]/
mit einem zusätzlichen htaccess Schutz sichert, in diesem Fall raten wir unbedingt dazu.
Jeder der phpMyAdmin auf diese Weise einsetzt, sollte sich im klaren sein, dort die Software auch mit Sicherheitsupdates zu patchen [B][U]UND[/U][/B] zusätzlichen Schutz per .htaccess hinzufügen.
Daher hier mal eine beispielhafte [B].htacess[/B]:
AuthType Basic
AuthName Intern
AuthUserFile [I][U]$path_to_your_htpasswd_file[/U][/I] #eg .htpasswd
require valid-user
Order deny,allow
Deny from all
Allow from [I][U]192.168[/U][/I] # insert your Client-IP here
Satisfy [I][U]all[/U][/I] # [all|any] get double-protection with all, a little less protection when any is used
RewriteEngine on
# Allow only GET and POST verbs
RewriteCond %{REQUEST_METHOD} !^(GET|POST)$ [NC,OR]
# Ban Typical Vulnerability Scanners and Script Kiddies
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(libwww-perl|curl|wget|python|nikto|wkito|pikto|scan|acunetix).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]
# Ban Search Engines, Crawlers
RewriteCond %{HTTP_USER_AGENT} ^.*(AdsBot-Google|ia_archiver|Scooter|Ask.Jeeves|Baiduspider|Exabot|FAST.Enterprise.Crawler|FAST-WebCrawler|www\.neomo\.de|Gigabot|Mediapartners-Google|Google.Desktop|Feedfetcher-Google|Googlebot|heise-IT-Markt-Crawler|heritrix|ibm.com\cs/crawler|ICCrawler|ichiro|MJ12bot|MetagerBot|msnbot-NewsBlogs|msnbot|msnbot-media|NG-Search|lucene.apache.org|NutchCVS|OmniExplorer_Bot|online.link.validator|psbot0|Seekbot|Sensis.Web.Crawler|SEO.search.Crawler|Seoma.\[SEO.Crawler\]|SEOsearch|Snappy|www.urltrends.com|www.tkl.iis.u-tokyo.ac.jp/~crawler|SynooBot|[email protected]|TurnitinBot|voyager|W3.SiteSearch.Crawler|W3C-checklink|W3C_Validator|www.WISEnutbot.com|yacybot|Yahoo-MMCrawler|Yahoo\!.DE.Slurp|Yahoo\!.Slurp|YahooSeeker).* [NC]
RewriteRule .* - [F]
Die nötigen Anpassungen sind kursiv gestellt.
Der Rewriteteil ist direkt aus phpMyAdmin/Contrib übernommen, so hält man die meisten Bots automatisch draussen, ebenso die Script-Kiddies. Und damit nicht einer meckert, wir hätten es nicht erwähnt:
[B]/admin/pma.php[/B]:
wobei [I][$add_random_string][/I] durch eine beliebige Zeichenkette ersetzt werden sollte, z.B. eine von hier. Das phpMyAdmin natürlich dann auch in diesen Order gehört sollte selbstverständlich sein
[QUOTE=sonntagmorgen;98735]Jeder der phpMyAdmin auf diese Weise einsetzt, sollte sich im klaren sein, dort die Software auch mit Sicherheitsupdates zu patchen [B][U]UND[/U][/B] zusätzlichen Schutz per .htaccess hinzufügen.
Daher hier mal eine beispielhafte [B].htacess[/B]:
...
RewriteEngine on
# Allow only GET and POST verbs
RewriteCond %{REQUEST_METHOD} !^(GET|POST)$ [NC,OR]
# Ban Typical Vulnerability Scanners and Script Kiddies
RewriteCond %{HTTP_USER_AGENT} ^(java|curl|wget).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(libwww-perl|curl|wget|python|nikto|wkito|pikto|scan|acunetix).* [NC,OR]
RewriteCond %{HTTP_USER_AGENT} ^.*(winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner).* [NC,OR]
[/QUOTE]
Wichtig: bitte nicht die .htaccess vom Shop anpassen, denn gerade die Suchmaschinen werden euch dafür bestrafen ;)
Plus: einige externe dienste könnten gerade curl/wget als datenzugriff nutzen :) aber einen echten Schutz bietet dieses manipulierbare Feld (User-Agent) zum Glück/leider nicht!!!
[QUOTE=FibreFoX;99256]Wichtig: bitte nicht die .htaccess vom Shop anpassen, denn gerade die Suchmaschinen werden euch dafür bestrafen
Plus: einige externe dienste könnten gerade curl/wget als datenzugriff nutzen aber einen echten Schutz bietet dieses manipulierbare Feld (User-Agent) zum Glück/leider nicht!!![/QUOTE]
Nur damit hier keine Mißverständnisse auftreten nochmal in aller Deutlichkeit:
Die oben genannte .htaccess [B]liegt an folgender Adresse: admin/phpMyAdmin_[I]sdzuhbtrzt[/I]/.htaccess[/B]
Es geht nicht um die htaccess für den Shop sondern nur um die im phpMyAdmin Unterverzeichnis. Wer das in der Hauptdatei einträgt wird relativ schnell feststellen, das er auf seinen Shop eh nicht mehr zugreifen kann:
Order deny,allow
Deny from all
Allow from 192.168
Das Curl/wget auf eine phpmyadmin-Installation [U]sinnvoll[/U] zugreifen glaube ich eher nicht, insofern ist die Einschränkung dort nicht verkehrt. (Auch wenn sie keinen 100% Schutz bieten können, aber es ist immerhin ein Baustein von mehreren)
dieses Thema ist schon älter und vermutlich gibt es mittlerweile weitere Lösungen.
Dennoch habe ich versucht das einmal nachzustellen.
Ich habe ein Modul geschrieben und kann das auch aktivieren. Der Menüeintrag erscheint auch. Wenn ich allerdings darauf klicke, dann erhalte ich statt der phpmyadmin Seite meine Shopstartseite in der Mitte der Admin Oberfläche.
Wenn ich die PHP Seite meiner Klasse (siehe oben) aufrufe erhalte ich zudem einen HTTP500 Error. Ob das etwas mit dem Problem zu tun hat weiß ich nicht.
Ich bin dahingehend von der oben genannten Vorgehensweise abgewichen, dass ich eine metadata.php erstellt habe und dort im $aModule Array einen Eintrag unter ‘files’ mit meiner Klasse erstellt habe.
Ist das überhaupt notwendig, wenn ich die menu.xml mit der entsprechenden Klassenbezeichnung bestücke?
Ich habe also neben den oben genannten Dateien noch folgenden Eintrag:
ja, weil der Shop sonst gar nicht weiß, wo er diese Klasse suchen soll.
Im ursprünglichen Beitrag liegt pma.php im Shop-Verzeichnis mit anderen Controllern und nicht im Modul-Verzeichnis
ich habe die Beiträge nur kurz überflogen, aber wenn es mit dem files Eintrag in der metadata.php funktioniert, dann ist alles korrekt.
OXID hat einen Ordner, wo die ganzen Klassen liegen, dort würde er standardmäßig nach der Klasse “pma” suchen.
Zum Zeitpunkt der Erstellung dieser Anleitung war “admin” eben dieser besagte Ordner und im ersten Beitrag ist die Rede davon, diese Klasse direkt in dem Ordner anzulegen: admin/pma.php
Dadurch, dass du die Klasse aber in deinem Modulordner hast, findet OXID sie natürlich nicht im standard Ordner (der bei der aktuellen Version übrigens wo anders ist) und du musst diese Klasse “pma” erst mal mit Hilfe des metadata.php files Eintrages in OXID registrieren, dann weiß OXID, dass die Klasse “pma” sich in deinem Modul in dem angegebenen Ordner befindet und kann sie findenn
