Frames ersetzbar durch...?

[Sebastian]

Hallo,

ich überlege, da es für Verlinkungen, Pagerank usw günstiger sein wird doch auf Frames zu verzichten. Allerdings will ich gern trotzdem unten an der Seite einen festen Platz wo Werbung dargestellt wird und links einen festen Platz wo die Navi ist. Also nicht wie bei normalen PHP-Seiten, wo die Navi einfach weggescrollt wird wenn man im Content weiter unten im Text ist.
Die meisten PHP-Seiten wo alles auf einer Seite ist sind ja per Tabelle aufgebaut. Es gibt einen CSS-Trick mit dem man Zellen Scrollbalken geben kann. Allerdings ist css ja nicht von allen Browsern unterstützt und zeigt wohl auch oft unterschiedliche Ergebnisse.
Wie könnte man das trotzdem auf einer Seite umsetzen. Es soll natürlich auch von allen Browsern möglichst verstanden werden und korrekt dargestellt werden. Also irgendwelche Javascripttricks will ich da nicht nutzen. Es sollte möglichst alles HTML oder php sein bzw auch verstanden werden von den Browsern.
Oder wäre es möglich, statt einer Framedefinition und drei Frames nur eine Framedefiniton mit Werbeframe und Naviframe zu bauen und den Content in die Framedefionition? Geht das überhaupt? Dann wären die Navi und die Werbung zwar ausgelagert aber das wäre nicht so schlimm. Und der Content wäre direkt in der ersten Lesebene.

Wie kann ich die alten Seiten in der .htaccess auf die neuen Seiten verlinken? Kann man auch mehrere "Permanent verzogen" eintragen und alle werden beachtet?
Ich habe zB ein verzogen für die URL ohne www auf www geleitet. Werden Befehle die danach kommen zB von Navi.htm auf seite.php auch noch abgearbeitet?

Wie ist es mit der Sicherheit von Mysql-Paßwörtern in php-Dateien? Sind die sicher oder kann man die auslesen? Was ist wenn php auf dem SErver abstürzt? Und was ist mit includes die eine andere Endung haben. ZB .inc? Kann man die Dateien absichern damit niemand das Paßwort auslesen kann?

Grüße,
Sebastian

[dedlfix]

echo $begrüßung;

Wie ist es mit der Sicherheit von Mysql-Paßwörtern in php-Dateien? Sind die sicher oder kann man die auslesen? Was ist wenn php auf dem SErver abstürzt? Und was ist mit includes die eine andere Endung haben. ZB .inc? Kann man die Dateien absichern damit niemand das Paßwort auslesen kann?

Definiere "niemand". Wenn es dir um Zugriffe über HTTP geht, kannst du die kritischen Dateien außerhalb des DocumentRoot ablegen. PHP kann dann immer noch darauf zugreifen und für den Webserver sind sie quasi nicht vorhanden.

Geht es um einen Server, der mehrere (nicht befreundete) Projekte beherbergt, sind entsprechend den jeweiligen Implementierungsdetails der geteilten Umgebung die Zugriffsberechtigungen zu beachten / zu setzen.

echo "$verabschiedung $name";

[Sebastian]

Definiere "niemand". Wenn es dir um Zugriffe über HTTP geht, kannst du die kritischen Dateien außerhalb des DocumentRoot ablegen. PHP kann dann immer noch darauf zugreifen und für den Webserver sind sie quasi nicht vorhanden.

Das wäre eine Idee. Ich muß mal schauen ob ich oberhalb des html-Verzeichnisses ein Verzeichnis erstellen kann. Bzw ob ich mit php überhaupt über die Domain hinausgehen kann. Das rootverzeichnis ist in html ja das Verzeichnis html. Und ob ich darüberhinausgehen kann muß ich erstmal testen. Vielleicht kann man ja auch ein Verzeichnis in HTML erstellen, daß nur vom System aber nicht von Usern gelesen werden kann. Mit .htaccess?

Muß ich mal testen.

Grüße,
Sebastian

[Auge]

Hallo

Das wäre eine Idee. Ich muß mal schauen ob ich oberhalb des html-Verzeichnisses ein Verzeichnis erstellen kann. Bzw ob ich mit php überhaupt über die Domain hinausgehen kann. Das rootverzeichnis ist in html ja das Verzeichnis html.

Sieht die Struktur in deinem frp-Programm etwa so aus?

-tmp
-log
-html <-- hier ist die root für den Zugriff mittels http
-files
...

Wenn du jetzt noch selbst das Verzeichnis festlegen kannst, in dem die index.html/php liegt, also welches die root für die Seite ist, kannst du diese auch in ein unterverzeichnis von "html" verschieben. Sähe dann so aus:

-html
  -config <-- hier die zu schützenden PHP-Dateien rein
  -deine_seite <-- hier ist die neue root für die Seite
     -css
     -grafik
     .... (u.s.w. u.s.f.)

Die Seite wird aus dem Verzeichnis "deine_seite" heraus aufgerufen, auf "config" hat man per http keinen Zugriff, ein PHP-Skript aber schon, da das Verzeichnis "html" dir als User gehört und ein include über den lokalen Dateipfad aufgerufen wird, nicht über den URI.

Tschö, Auge

[Sebastian]

Hallo Auge,

das Verzeichnis sieht so ähnlich aus:

.configs
atd
backup
files
html
log
phptmp
restore

Und in html liegt die index.htm(ist ja noch htm).

Muß ich dafür nicht eine neue Domain anlegen? Ich meine wenn ich nur festlege wo die index liegt, dann ist der root doch immer noch unter html oder? Die Index wird nur in einem Unterverzeichnis aufgerufen.
Naja. Werd mich erstmal daran machen meine Firmenseite zu verbessern. Soll professioneller aussehen. Einfachheit ist wohl auf den ersten Blick nicht immer vorteilhaft. Und der erste Blick ist ja der Wichtigste. Na dann werd ich halt so eine Webseite haben wie sie alle haben... Was solls. :-)

Grüße,
Sebastian

[Auge]

Hallo

das Verzeichnis sieht so ähnlich aus:

.configs
atd
backup
files
html
log
phptmp
restore

Und in html liegt die index.htm(ist ja noch htm).

Muß ich dafür nicht eine neue Domain anlegen? Ich meine wenn ich nur festlege wo die index liegt, dann ist der root doch immer noch unter html oder? Die Index wird nur in einem Unterverzeichnis aufgerufen.

Wenn dir dein Provider die Wahl des Rootverzeichnisses lässt [1], dann bedeutet das, dass du ein jegliches Verzeichnis unterhalb "html" als root für deine Domain nutzen kannst. Das von dir angegebene Verzeichnis, und _nicht_mehr_ "html", ist dann die root. In "html" kannst du dann deine config-Dateien ablegen, die z.B. von PHP gelesen, aber nicht für den Besucher sichtbar sein sollen.

[1] Dies kann der Fall sein, wenn du z.B. mehrere Domains in diesem Webspace lagern oder Subdomains anlegen kannst.

Tschö, Auge

[Sebastian]

Stimmt. Ich brauch ja keine neue Domain anlegen. In Confixx kann ich das "weiterleiten nach" ja ersetzen. Im Moment ist da ein Forwardslash.
Da bin ich gar nicht draufgekommen. Hab da nämlich noch eine Domain auf dem Server und die lag immer in einem Unterverzeichnis. Jetzt kann ich das ordentlich auf gleichem Level ablegen. *g*

Ich werd das mit dem php auch so machen. Viele Scripte kann ich ja auch nur einmal schreiben und dann per Include einbinden für verschiedene Domains. Werd dann je ein php-Verzeichnis für eine Domain und ein gemeinsames anlegen. Und der Rest liegt dann in einem Verzeichnis extra pro Domain, also Bilder usw.

Guter Tip. Dann wird das gleich ordentlicher aussehen. :-)

Grüße,
Sebastian

[Sebastian]

Wie ist das eigentlich wenn jemand /../ benutzt? Also zb ich habe eine index.php und durch die binde ich alle incs und php-code aus einem verzeichnis über dem rootverzeichnis ein. Wenn nun jemand an den Inhalt der index.php rankommt und die namen bzw pfade der includes auslesen kann, dann könnte er doch zb über www.abd.de/.../php/passwort.inc zugreifen oder? ZB wenn php abgestürzt ist. Oder ist da eine Grenze die er nicht durchbrechen kann?

Grüße,
Sebastian

[at]

Hallo.

Wie ist das eigentlich wenn jemand /../ benutzt? Also zb ich habe eine index.php und durch die binde ich alle incs und php-code aus einem verzeichnis über dem rootverzeichnis ein. Wenn nun jemand an den Inhalt der index.php rankommt und die namen bzw pfade der includes auslesen kann, dann könnte er doch zb über www.abd.de/.../php/passwort.inc zugreifen oder? ZB wenn php abgestürzt ist. Oder ist da eine Grenze die er nicht durchbrechen kann?

Das kommt auf deine Konfiguration respektive die Rechtevergabe an.
MfG, at

[Sebastian]

Das kommt auf deine Konfiguration respektive die Rechtevergabe an.

Da weiß ich leider gar nicht wo ich da nachsehen muß. Bzw wo bei dem Provider.
Vielleicht reicht ein einfacher test ob man es in der url direkt aufrufen kann.

Grüße,
Sebastian

[at]

Hallo.

Und in html liegt die index.htm(ist ja noch htm).

Du solltest DOS durch ein Betriebssystem ersetzen.
MfG, at

[Sebastian]

Du solltest DOS durch ein Betriebssystem ersetzen.

Na so schlimm ist es nicht. Hatte das glaube ich anfangs wegen Kompatibilität so gemacht.

Grüße,
Sebastian