Seite 2 von 4

Verfasst: 21.12.2006, 13:34
von AnjaK
Michael1967 hat geschrieben:Beste Lösung wäre hier wohl die Dateien und zusätzlich Updates als Datei.

Dann könnte jeder selbst seine Dateien aktuallisieren.
Naja, dann kann man auch gleich eine Autoupdate-Funktion einbauen, denn das ist ja im Prinzip das Gleiche nur ohne Userzutun.

Verfasst:
von
Content Erstellung von ABAKUS Internet Marketing
Ihre Vorteile:
  • einzigartige Texte
  • suchmaschinenoptimierte Inhalte
  • eine sinnvolle Content-Strategie
  • Beratung und Umsetzung
Jetzt anfragen: 0511 / 300325-0

Verfasst: 21.12.2006, 13:35
von Airport1
> Beste Lösung wäre hier wohl die Dateien und zusätzlich Updates als Datei.

Selbst wenn die Sperrdaten in ne extra Datei muessten, muesste selbiger wieder chmod 777 sein. Es waere also nichts gewonnen.

Die Laufzeit des Scripts wuerde sich dazu dann noch verschlechtern, da das Script die Sperrdaten erst reinladen / includen muesste.

Weitere Vorschlaege ;) ?

Verfasst: 21.12.2006, 13:36
von Michael1967
Es selbst zu tun ist aber die bessere Lösung. Dann kommen solche Fragen wie in diesem Post erst gar nicht auf :D

Verfasst:
von

Verfasst: 21.12.2006, 13:38
von AnjaK
Ok, das mit der Serverlast kann ich nachvollziehen.

Was das AdSense angeht: Da solltest du dich mal beraten lassen ;)
Dort wo deine Werbung ist, klickt eh kaum jemand, vor allem keine Webmaster ;)

Wenn du die 777 als KGN nimmst dann mach doch eine Alternativlösung für die, die kein Autopudate wollen, damit sich diese das Update runterladen können. Als Zwischenlösung sicherlich keine der schlechtesten Varianten!
Airport1 hat geschrieben:Das mit dem "vom Server includieren" kann man m.E. fuer diesen Anwendungsfall absolut knicken, da wie gesagt dann nicht nur der Server sehr belastet waere, sondern eine Menge unnoetiger Netzwerklatenzen bei den Nutzern entstehen wuerden.

Ueber Werbung/Adsense kommt derzeit nichts rein (ab und zu mal 3 Cent am Tag oder so), wahrscheinlich sind die User zu gebildet um zu klicken ;-)

> Dann versteh ich nicht, warum es 777 braucht um sich selber zu überchreiben?

Wir haben voellig verschiedene Server Configs. Der eine mag nicht bei 644, der andere jenes nicht. Es ist wieder mal der kleinste gemeinsame Nenner, damit es bei allen Nutzern funktioniert. Ich wollte urspruenglich auch nicht die 777.
Boah... eine Million Tippfehler! Wer schenkt mir zu Weihnachten eine neue Tastatur? Mit ganz großen Tasten für halbblinde alternde SEÖsen :D

Verfasst: 21.12.2006, 13:39
von Airport1
> Da diese Textdatei aber auf deinem eigenen Server liegt, wäre das nicht das Problem, da du auf deinem eigenen Server ein Zwischenscript platzieren kannst, dass per chmod den Zugang öffent und danach gleich wieder schließt.

Wir haben voellig verschiedene WebServer Configs. Manche sind so restriktive eingestellt/konfiguriert dass ein PHP Script gar nicht die Rechte (chmod) eines anderen aendern darf. Das muesste dann ein Perl Script machen, da geht das meistens ;)

Verfasst: 21.12.2006, 13:41
von Airport1
Wer kein Auto Update moechte oder Sicherheitsbedenken hat, muss nicht die chmod 777 Rechte setzen. Er hat dann bislang nur das Problem wie er selber ein Update an Land zieht. Aber die neue Version kommt bestimmt ;)

Verfasst: 21.12.2006, 13:41
von AnjaK
<< Das muesste dann ein Perl Script machen, da geht das meistens

Naja, ein Perlscript, dass eine Datei "chmodded" sollte doch nicht DAS Hindernis sein oder? ;)

Verfasst: 21.12.2006, 13:42
von AnjaK
Naja, wie gesagt, die Datei auf deinem Server als Update zur Verfügung zu stellen sollte nicht so das große Problem sein ;)

wir schreiben ständig aneinander vorbei, der eine ist schneller als die andere *lacht*
Airport1 hat geschrieben:Wer kein Auto Update moechte oder Sicherheitsbedenken hat, muss nicht die chmod 777 Rechte setzen. Er hat dann bislang nur das Problem wie er selber ein Update an Land zieht. Aber die neue Version kommt bestimmt ;)

Verfasst: 21.12.2006, 13:43
von Michael1967
Airport1 hat geschrieben:Wer kein Auto Update moechte oder Sicherheitsbedenken hat, muss nicht die chmod 777 Rechte setzen. Er hat dann bislang nur das Problem wie er selber ein Update an Land zieht. Aber die neue Version kommt bestimmt ;)
Man könnte den Download doch einfach aktuallisieren, wenn etwas "Neues" dazugekommen ist.

Neu runterladen auf den Server damit und jut is!

Verfasst: 21.12.2006, 13:45
von Airport1
> Naja, ein Perlscript, dass eine Datei "chmodded" sollte doch nicht DAS Hindernis sein oder?

Das nicht. Aber der KGN besagt dass viele gar kein PERL auf Ihrem Server installiert haben! Der KGN muss leider rigoros bedacht werden. Selbst wenn man das voraussetzen koennte, wir haben tw. 70jaehrige User, die wuerden verzweifeln wenn erstmal ihr Perl Script einen 500 Internal Server Error werfen wuerde ;)

Verfasst: 21.12.2006, 13:59
von AnjaK
Nein du verstehst mich falsch. Das Perscript soll ja auf DEINEM Server laufen und auf DEINEM Server per .txt-Datei die Bösewichtdaten zur Verfügung stellen.
Das geht aber auch mit php auf deinem Server.

Das Script kann festhalten (in DEINER Datenbank), ob der UserX bereits die aktuelle Version hat. Hat er sie, muss das Script das auf dem USERSERVER liegt nicht mehr auf die Daten zugreifen. Hat es NICHT die aktuellen Daten, erhält es von deinem Script die Daten gesendet bei Anfrage um sie dann selbstständig zu speichern in einer textdatei auf dem USERSERVER, damit nicht immer auf DEINE Datei zugegriffen werden muss. Somit hättest du keine Serverlast und der User keine Sicherheitslast.

Verfasst: 21.12.2006, 14:05
von Airport1
> um sie dann selbstständig zu speichern in einer textdatei auf dem USERSERVER

..dazu benoetigt aber der userserver bzw. die textdatei ebenfalls wieder 777 - zum ueberschreiben. und wenn ich auf einem server eingeloggt bin kann ich nich nur diese txt datei ueberschreiben, ich kann sie m.E. auch renamen zu einer php datei - dann ist ja wieder nix gewonnen ;)

Verfasst: 21.12.2006, 14:11
von chris21
Anja: ich weiß nicht so recht, ob ihr beide nicht aneinander vorbei redet:

also, ein update erreicht man dadurch, dass man den page.restrictor durch ?pres=udate aufruft. Alternativ kann man seinen p.r. eintragen lassen, so dass immer bei einem neuen Update der page-restrictor mit ?pres=update aufgerufen wird.

Bei Aufruf von ?pres=update fragt der page-restrictor auf dem Server von bot-trap nach, ob dort neuere Daten liegen, wenn ja, schnappt er sich die Daten und überschreibt seine alten Daten. Es wird aber nicht von außen ein Befehl gestartet, durch den die Daten überschrieben werden, dies wäre aufgrund des fehlenden Besitzers des Scriptes auch nicht möglich. Beachte: sowas wie fput etc. funzt nicht über http.

Daher verstehe ich nicht, wo Du dort ein Risiko siehst. Dies würde nur auftauchen, wenn Dein gesamter Server mit 777 offen wäre bzw. bei Shared Hosting Dein oberster Public Ordner.

Verfasst: 21.12.2006, 14:18
von Airport1
Muss Euch leider nun die naechsten 2-3 Stunden alleine lassen, also nicht wundern "wenn nix mehr kommt"..

Sport ist Mord. Moechte aber ja auch nicht als "SEO mit Pizza-und-Bier-Wampe" enden ;)

Verfasst: 21.12.2006, 16:56
von AnjaK
<< Anja: ich weiß nicht so recht, ob ihr beide nicht aneinander vorbei redet:

Ja, das tun wir in der Tat ;)

<< Daher verstehe ich nicht, wo Du dort ein Risiko siehst. Dies würde nur auftauchen, wenn Dein gesamter Server mit 777 offen wäre bzw. bei Shared Hosting Dein oberster Public Ordner.

Wie gesagt, ich kenne mich mit der Serverumgebung nicht so sehr aus, das ist der Job meiner bessern Hälfte, ich "weiß" nur, dass ich mit 777 auch von außen an das Script komme. Mag sein, dass ich da falsch informiert bin, durchaus drin ;)

Aber wie gesagt, das Tool ist sehr gut, aber einen 777er bekommt das Script bei mir nicht, da muss ne andere Lösung her ;)