ZitatWobei bei beiden die Hochkommas fehlen. Ob das aber notwendig
ist weiß ich jetzt nicht.
bewirkt beides das gleiche du nub
ZitatWobei bei beiden die Hochkommas fehlen. Ob das aber notwendig
ist weiß ich jetzt nicht.
bewirkt beides das gleiche du nub
Zitatbackground-image: url(../Bilder/Unbenannt-2_01.png);
background:url(../Bilder/Unbenannt-2_01.png);
Sieh außerdem zu dass das bild im richtigen Verzeichnis liegt. Wenn du für die css nen eigenen ordner hast a`la /css und das Verzeichnis Bilder, darunter liegt, dann is die Anwendung richtig. Wenn aber das Verzeichnis Bilder im selben Verzeichnis wie die CSS Datei liegt kannste das "../" weglassen.
Falls das außerdem nich funzt ersetz mal <a id="2"></a> durch <div id="2"></div> und gib ne Rückmeldung.
~Lunatic
ZitatAls Krönung wäre ASM noch gut, aber das ist kein muss, solange du nich grade Reverse Engineering machen willst oder so.
Ich würde ASM eher separieren. Es is eben ne Maschinensprache und keine Hochsprache wie die oben erwähnten. Es is auch sinnlos Programme in Assembler zu schreiben und wie gesagt eher dazu gut reverse engineering zu betreiben oder eben Sources zu bearbeiten.
Aber es zu erlernen will ich keinem zumuten, dass is die reinste Tortur ... ich freu mich total auf 12/1 wo ich das dann lernen darf -.-
~Lunatic
Vergiss alle vorigen Statements lieber Sasuke.
2-3 Jahre, 10-15 Jahre, 20-30 Jahre...
Alles quatsch.
It`s done when it`s done. Jeder braucht so lange wie er braucht und wie er willig is etwas zu lernen. Es kann sogar sein dass man ein paar Anläufe benötigt um dann die Motivation hat eine Sprache zu erlernen. Auch wenn ich solche Fragen wie die Pest hasse... will ich dir auf die Sprünge helfen.
Ich würde dir Vorschlagen nicht gleich eine Hochsprache wie C++ zu lernen, da man dort u.a mit Pointern arbeitet. Versuch dich, um dir allgemeines Programmierverständnis anzueignen vielleicht erstmal an Skriptsprachen. Die Motivation dort ist wesentlich höher, da man schneller Erfolge feiern kann.
Die Grundprinzipien die du dort lernst, lassen sich auf so gut wie jede andere Sprache übertragen. If Anweisungen, Schleifen, etc... um diese wirst du in keiner Sprache drumrumkommen (außer Schleifen in ASM xD). Dann würde ich dir vorschlagen um OOP zu lernen eine Sprache wie Java zu erlernen. Wäre Java schneller, hätte sie C++ längst überholt. Ab da gibts für dich zwei Möglichkeiten: Du hast kB mehr auf C++ da du Java eh geiler findest, oder aber du lernst andere Sprachen im Schlaf da einer der anderen gleicht ...
~Lunatic
ZitatLol, wieso hat der noob alle seine Eigenschaften und
Methoden Statisch gemacht.. =O
Weil er den Zweck von OOP nicht erkannt hat. Die Datenbankklasse kann man aber schon ruhig statisch machen, dagegen gibts keine Einwände. Aber dem Stil nach zu Urteilen is alles Statisch.
Zitat
Oder man verwende das USE Statement. Für genaueres gibts ja
zum glück g3wgl3
Du hast mir gefällt Schätzchen :( Aber wollen wir bereits bei deiner Rückkehr so gemein sein?
Try following @ Threadstarter
("USE [DATENBANKNAME_DBF] SELECT * FROM ACCOUNT_TBL WHERE account = '".$str."'");
~ Lunatic
Zitat
Derjenige der das Bild gemacht hat kennt MMorpg-Core nicht mal.Emu-Cube war sogar schon Online als hier alles noch GodlikerZ hieß und da hatten wir das Forum auch schon, also wer hat hier was geklaut.....
Und wieder jemand der sich mit den falschen Leuten anlegt. Achja um die Sache jetzt hier zu begraben und daraus keine eigene Diskussion zu machen.
Das Logo wurde von meinem besten Kumpel erstellt... an meinem Rechner. Ich kann bestätigen, dass das Logo aus eigener Kreation heraus entstanden ist.
Das zweite Argument ist, wie schon erwähnt, dass es das Logo bereits vor der entstehung von eurer "Community" entstanden ist.
Weitere Diskussionen erübrigen sich jetzt wohl.
~Lunatic
Hallo Community,
momentan bin ich grad am schreiben eines kleinen PHP Frameworks für meine zukünftigen Projekte. Eine Sache die mich immer gestört hat, war das auswerten von Formularen.
Für jedes Formular musste eine extra-Auswertung erfolgen was tierisch genervt hat. Deshalb habe ich mir überlegt eine kleine Klasse zu basteln die mir automatisch Formulare parst.
Dem Formular übergibt man durch den {formparser}-Tag Parameter, welche dann später über PHP ausgewertet werden. Da ich ein Templatesystem geschrieben habe, wird vor der Ausgabe des parses, die Formparser Klasse aufgerufen, welche die Formulare noch einmal extra parst.
Kleines Beispiel:
{formparser=name: formular; maxlen: 12; numeric: no}<input type="text" name="formular" />{/formparser}
Besagt, dass dieses Feld maximal 12 Zeichen haben darf, sowie nicht numerisch sein darf.
Da ich Regex erst lernen musste habe ich für den Formparse erst ein paar Tests gemacht, welche ich mit der Öffentlichkeit teilen werde, da sie Webdevs möglicherweise zu ähnlichen Ideen anregt.
Der Code bisher is crappy und kann fehlerhaft sein. Der Schwerpunkt liegt bisher eben nur darin die Parameter auszulesen und die entsprechenden Formularfelder zu überprüfen.
<form action="" method="POST">
{formparser=name:shice; dynname: XY; maxlen: 12; numeric: no;}<input type="text" name="shice" />{/formparser} <br />
<input type="submit" name="sub" />
</form>
<br />
<br />
<?php
$regex = '#\{formparser=(.*)\}(.*)\{/formparser\}#';
$string = preg_match_all($regex, file_get_contents(__FILE__), $result);
$params = explode(";", $result[1][0]);
$parseaguments = array();
foreach($params AS $key => $value){
if($value){
$explstring = explode(":",$value);
$parsearguments[trim($explstring[0])] = trim($explstring[1]);
}
}
$erray = array();
foreach($parsearguments AS $key => $value){
switch($key){
case 'maxlen':
if(strlen($_POST[$parsearguments['name']]) > $value){
$erray[] = "Die Maximale Zeichenlänge von ".$parsearguments['dynname']." beträgt ".$value." Zeichen";
}
break;
case 'numeric':
if($value=='no' && is_numeric($_POST[$parsearguments['name']])){
$erray[] = $parsearguments['dynname']." darf keine Zahlen enthalten";
}
else if($value=='yes' && !is_numeric($_POST[$parsearguments['name']])){
$erray[] = $parsearguments['dynname']." muss numerisch sein";
}
break;
}
}
if(count($erray) > 0){
foreach($erray AS $key => $value){
echo $value."<br />";
}
}
else{
echo "Eingabe korrekt";
}
?>
Alles anzeigen
Schlagt mich nicht für den Code, der wird so auch keine Anwendung in der späteren Klasse finden.
Dieses Snippet sollte wie es oben steht, nicht verwendet werden. Da keine Sicherheitsvorkehrungen bei Usereingaben getroffen worden sind.
Genaueres ist in meinem Blog nachzulesen:
Lunatic Stories
~Lunatic
Zitat@TwiLight : Bitte lies das Thema bevor du dumme Post schreibst. Dankeschön mag dich auch.
Schnucki? Ich glaub du hast so einige Sachen noch nicht verstanden.
Hier gibt es ein paar Leute mit denen man sich besser nicht anlegen sollte, da sie dich sonst möglicherweise zum weinen bringen könnten.
Solche unterbelichteten dummen Kommentare bringen mich nur unnötig auf die Palme und das um 10 vor 7 Morgens o.O
Was Twilight sagt is eben nunmal die Wahrheit und wieso sollte man ein Blatt vor den Mund nehmen?
Die Rechtschreibung ist wirklich fail. Die Aufmachung ist fail. Deine Projektplanung ebenfalls. Und wenn du dann meinst mit deiner möchtegern-Zynik hier ankommen zu müssen, dann bin ich wahrscheinlich nicht der einzige dem sowas auf den Senkel geht.
~Luna
wtf?! Warum sollte er es nicht? o.O
schau in der .css nach der "logo" Klasse. Da redefinierste width und height einfach...
~Lunatic
Ich frage mich nur, was genau du haben willst. Buttons? Verzeichnisse, Text?
Ganz simple Frage:
Du hast ne Textarea, schreibst dort etwas rein. Drückst auf einen absenden Button und kannst anschließend die news auf nem anderen Bereich der Website sehen?
Ist das deine Intention?
~Luna
Simpel aber cool :)
~Luna
ZitatEs wär gut wen ein Root ect. vorhanden ist. Das Team sollt etwas von FlyFF verstehen sowie von sein Handwerk.
Und was wäre deine Aufgabe im Team? Holst du Kaffee für die Staff-Member?
Du hast keinerlei deiner Vorzüge aufgezählt, wieso zur Hölle sollte dich also ein Serverprojekt aufnehmen. Weder dein Name zeugt von Kompetenz, noch sind deine Designqualitäten (der Signatur nach zu urteilen) so weit, dass ein gutes Projekt dich aufnehmen würde.
Bei "0815" Projekten hättest du allerdings eine Chance.
Überarbeitung oder löschung dieses Threads ist hier angesagt.
~Lunatic
Zitatmysql_ist_sicher() - XSS auch^^
Okay sorry =) Der Funktionsname ist eben ein bisschen ungünstig gewählt.
ZitatFeldnamen mache ich generell eig wenig in ''
Solltest du dir aber angewöhnen =) Felder die `date` heißen (z.B.) braucht man desöfteren.
~Luna
ZitatDann ist aber das komplette Niveau dieser Sektion so ziemlich am Arsch oder habt ihr die Genehmigung von Aeonsoft ihre Files zu benutzen? ;)
Lese ich da einen leicht zynischen Unterton heraus xP?
Jap da haste Recht, dass is ein Argument, ein ziemlich schwer zu schlagendes sogar.
Allerdings kann ich dazu sagen, dass die pServer Szene (nicht FlyFF, sondern generell) mittlerweile eine eigene Kultur geworden is und viele Talente fördert.
Du hast aber auch Recht. Es entsteht ein imenser Schaden den Unternehmen gegenüber.
Zitatgute Chancen
bedeutet ja nicht, dass eine 100% Chance besteht.
Dein Beispiel grenzt ja auch schon fast an organisierten krummen Dingern =)
Ich bin lediglich von ganz normalen Leuten ausgegangen, die sich nicht darüber im klaren sind was sie überhaupt tun :)
~Luna
Das Zauberwort heißt in diesem Falle, Fehlerbehandlung.
Lass dir MySQL Errors ausgeben, PHP stellt hierfür eine nette Funktion bereit:
PHP: mysql_error - Manual
Noch ein paar Dinge, die dich selbst zum denken anregen sollen:
1. mysql_ist_sicher xD - XSS nicht...
2. Feldnamen kommen bei Queries generell in `` (bsp: `feldname`). Es kann sein, dass MySQL eine Funktion hat, die den selben Namen besitzt wie dein Feldname. In diesem Falle liegt MySQL`s Priorität bei der Funktion. Da sie aber in diesem Zusammenhang nichts anzufangen weiß, spuckt er Errors.
3. Du übergibst als E-Mail einen leeren String
4. Also Geburtstag übergibst du "d.m.Y". Wenns dir passt das alle User an "d.m.Y" Geburtstag haben, dann ist das okay :)
Das sollte dich ne Weile beschäftigen =)
~Luna
Hallo liebe Community,
da ich es gerade schon wieder mitbekommen habe, dass wieder Scripts veröffentlich worden sind, habe ich aus gegebenem Anlass diesen Thread hier verfasst.
Und zwar geht es um dass veröffentlichen von Webscripts ohne die ausdrückliche Genehmigung des Autors bzw. der Autoren.
Ich werde hier nur auf Hobbycoder eingehen, da professionelle/komerzielle Webcoder gute Chancen haben, rechtlich gegen solche Leecher vorzugehen. Im Gegensatz zu Hobbycodern deren Chance rechtlich gegen solche Fälle vorzugehen gegen Null geht.
1.0 Hintergrund der Applikation
_______________________________________________________________
Schön und gut. Die Förderung des Open-Source Gedanken. Jemand schreibt einen Script und released in für die breite Masse. Sehr löblich und gegen die benutzung spricht nichts. Eher erfreut es den Autor dass sein Script so zahlreich genutzt wird. Kommen wir aber zur Schattenseite.
Ein Autor schreibt ein Script für einen bestimmten Zweck. Nennen wir das Kind mal beim Namen und machen da ein kleines Beispielchen dazu.
Jemand arbeitet für einen Privatserver, hat tolle Skills im Bereich WebDevelopment. Er schreibt eine eigens für diesen Privatserver gecodete Website mit allen möglichen, tollen Funktionen. Der Admin und das Team sind stolz auf den Developer, andere Privatserverbetreiber stechen sich die Augen aus und platzen anschließend vor Neid und User bekommen einen virtuellen Orgasmus.
2.0 Aufwand
_______________________________________________________________
Der Aufwand einer Webapplikation ist von Fall zu Fall unterschiedlich. Greifen wir aber mal unser obiges Beispiel auf.
Ein gutes Panel zu coden is keine Arbeit von 2 Wochen. Es stecken etliche Stunden darin. Wunde Finger, Kaffeeshocks und schlaflose Nächte sind Opfer, die Coder erbringen müssen um das Ziel zu erreichen.
Leecher haben gar keine Ahnung wie viel Arbeit in den 4 MB`s stecken, die sie auf ihrer Platte haben. Es ist eigentlich schon fast Ironie, dass in so wenigen Bytes, so viel Arbeit steckt.
3.0 Leechen
_______________________________________________________________
Unter "leechen" versteht man Umgangssprachlich, dass klauen, benutzen und/oder verbreiten von Dingen die nicht von ihnen gemacht wurden und von denen keine Genehmigung des Autors besteht, diese Dinge zu verwenden.
Leecher wissen nicht, was sie dem Scriptautor antun, besonders bei Webapplikationen ist das ein imenser Schaden der dem Autor entsteht.
Webapplikationen zu schützen ist nach einem Leech eigentlich nahezu unmöglich...
3.1 Nicht-Kommerzieller Zweck-----
_______________________________________________________________
... da ein PHP Script z.B. vorher nicht kompiliert wird. Man kann die Dateien einfach öffnen und bearbeiten.
Wird ein nicht kommerzieller Zweck verfolgt, so ist das Script meist für eine bestimmte Person bzw. Personengruppe geschrieben und auch nur diese haben dass Recht darauf es zu verwenden.
Nun gibt es zwei Arten von blödsinnigen, dummen Menschen durch die das Script released werden könnte:
a) ScriptkidDz0rs: Diese Gruppe von meist pubertierenden Teenagern, haben nichts besseres zu tun als auf einer Seite (auf die sie Meist neidisch sind) Krampfhaft nach Lücken zu suchen um sich dass Script herunterladen zu können. Anstatt dem Autor des Scripts zu helfen, meinen sie ihm den größtmöglichen Schaden zufügen zu müssen, in dem sie das Script releasen. Unter diese Kategorie fallen auch böse h4xX0rs die sich anderweitig Zugang zum Space verschaffen um sich das Script zu leechen.
b) Gefühlsgeleitete Ex-Teammember oder Vertrauenspersonen:
Diese Art ist eigentlich noch viel schlimmer, da ein Vertrauensbruch zwischen Scriptautor und Vertrauensperson zustande kommt.
Gemeint sind hiermit Personen, denen der Autor im Vertrauen Zugang zum Script ermöglicht hat und die es schamlos missbraucht haben.
So ist es entweder der Admin, der nach einem kleinen Streit mit dem Scripter aus Wut mal seine Arbeit released oder ein Teammember, der ein Team verlässt und selbiges tut.
3.2 Kommerzieller Zweck-----
_______________________________________________________________
Hier tuts weh. Manchmal möchten Scripter ihr Script kommerziell vertreiben und verlangen wenns etwas aufwendig ist, zurecht einen Obolus für den erhalt des Scriptes. Nach dem Eingang des Geldes bekommt der Kunde das Script.
Da wie oben bereits genannt kaum eine Effektive Möglichkeit besteht, dass Script zu sichern, muss der Autor dem Kunde Vertrauen. Und hier liegt auch das Arschloch begraben:
c) Kunde: Ein Kunde releast aus Lust und Laune einfach mal das Script, nichtmal unbedingt um dem Autor zu schaden, sondern einfach nur aus Lust und Laune eben.
Hierdurch würde sogar ein finanzieller Schaden für den Autor bestehen.
4.0 Also liebe Leecher...
_______________________________________________________________
Ich bin mir ziemlich sicher dass ich durch diesen geistreichen Beitrag niemanden konvertieren konnte nichts mehr zu leechen. Ich wollte aber nur aufzeigen wie verdammt weh es tut wenn so viel Arbeit einfach so, mir nichts, dir nichts entwertet wird.
Durch sowas stirbt die Motivation der Autoren, denn: "Warum etwas schreiben, wenn am Ende eh alles für die Katz' ist?"
Momentan, und ich bin da auch verdammt froh drüber, ist WebApp-Piraterie noch nicht sooo verbreitet hier in diesem Forum allerdings Vertrauen die Scripter denen, an die sie ihre Dinge weitergeben und wenn dieses Vertrauen eben gebrochen wird, dann brauch sich auch keiner Wundern warum dann mal Backdoors eingebaut werden.
Eine gewisse Vertrauensbasis sollte hier schon vorhanden sein. Autoren vertrauen ihren "Kunden" und bauen keine Backdoors ein und Kunden releasen nicht einfach Dinge die sie im Vertrauen bekommen haben.
Mein Apell an diese Minderwertige Randgruppe: Lasst den Shice sein, auf Dauer lohnt sich`s nicht. Kauft euch ein Buch und lernts selbst.
An alle anderen Leser hier hoffe ich, dass ich euch die Gefühlslage bei einem Release ein wenig näher beschreiben konnte.
Für Fragen und Anregungen bin ich wie immer, offen.
Grüße,
Lunatic
Was in dem Fall allerdings nicht viel bringen würde, da
a) Bei guten Konfigurationen sowas nicht möglich ist
b) Das Betriebssystem Passwort mit höchster Wahrscheinlichkeit nicht an das Webpanel gebunden ist.
~Lunatic
ZitatDa hat wohl einer Javascript gelernt x)
Mein Freund, guck dir mal das hier an... das hat nich im geringsten was mit Javascript zu tun: PHP: Manual Quick Reference
Wäre ja auch total schwachsinnig XSS Lücken Clientside zu fixen.
Achja und eine Sache möchte ich loswerden.
Egal wie etwas dermaßen komplexes gecodet is. Aber es nehmen und es zu releasen is wirklich armselig. An die die sowas geleechtes benutzen, ihr wisst nicht wieviel Arbeit in sowas drinsteckt und ohne die ausdrückliche Genehmigung des Autors eines solchen Scripts sollte es nicht benutzt werden. Sowas wäre Niveau unterster Klasse...
~Lunatic
Zitatweil meiner Meinung nach das prog nur n paar variablen aht um das inet vreizuschlaten
So ein quatsch q.q
Variablen sind doch nicht alles in PHP, sowas kommt nur wenn man gerade am lernen ist aber sonst nicht so die Ahnung hat : )
Ich werd mir das Teil bei gelegenheit mal ziehen und nach lücken schauen