Tárhely szolgáltató segítséget kér

domainflotta képe

Sziasztok!

Nagy fába vágtuk a fejszénket. Az ügyfeleink érdekében a következőt kezdtük el megvalósítani:

Azok a tárhelyes ügyfeleink, akik igényt tartanak rá rendszeres értesítőt kapnak arról, ha új biztonsági frissítés jelent meg a Drupalhoz.

Az értesítésben benne lesz a fontos tudnivalók és az is, hogy ha nem tudják megoldani a frissítést, akkor kihez fordulhatnak.

(Nagyon sok olyan cég van, akinek valaki beállított anno egy drupal rendszert olcsón, de támogatást nem adott hozzá. Érthető, hogy ezeket idővel a robotok feltörik)

Két dolgot szeretnék tőletek:

  • Hogyan lehet az adatbázis alapján egyértelműen megállapítani, hogy drupal rendszerről van szó és hol található az adatbázisban a verzió szám.
  • Ki az aki pénzért vállalná, hogy igény esetén elvégzi a szükséges frissítést az ügyfelünk drupal rendszerében

Lehetőleg az első pontra ide írjátok a válaszokat, míg a második esetén privátot kérek ár és kapacitás megjelölésével.

Ha esetleg rossz helyre írtam a kérésemet, kérlek jelezzétek, mert a törlés túl kevés információt hordoz.

ui.: Ha az elképzelésünkről van véleményed, azt is szívesen fogadom.

Illyés Edit képe

Nagyon jó ötletnek tartom.

Drupal webhelyek beazonosítására két jó módszer van:

1. http://isthissitebuiltwithdrupal.com/ :)

2. A HTTP header vizsgálata: http://www.lullabot.com/articles/is-site-running-drupal

Expires: Sun, 19 Nov 1978 (A Drupal-alapító Dries Buytaert születésnapja)

6
0
Illyés Edit képe

Viszont a kiegészítő modulokat is frissíteni kell. Igazából azok jelentik a nagy biztonsági kockázatot... Javaslom megnézni a Drush-t.

1
-1
domainflotta képe

Szóval akkor azt mondod, hogy hiába tudom meg a fő drupal verziót, mert lehet az friss, de a kiegészítő rejti a biztonsági kockázatot?

Ez a drush pontosan mire jó, mert megnéztem a linket, de nem lettem sokkal okosabb.

0
0
Illyés Edit képe

A fő verzió, a drupal.org-ról letöltött kiegészítő modulok és sminkek, saját fejlesztésű modulok és sminkek, nem megfelelően beállított jogosultságok... ajánlom a Cracking Drupal c. könyvet.

Drush: PHP parancssoros interfészre (CLI) épülő, a Drupal fájlrendszert és adatbázist menedzselő alkalmazás. Parancssorból lehet telepíteni, frissíteni, stb.

2
-1
domainflotta képe

Sajnos nem lehetünk minden cms szakértői. Azonban Drupalban ti vagytok a legjobbak.

A probléma a következő. Sokan telepítenek egy drupalt, beállítják az ügyfélnek és aztán eltűnnek.

A céges honlap működik, aztán egyszer csak jönnek a problémák a spamek és a feltörések miatt.

Ezt kizárandó arra gondoltunk, hogy felkutatjuk automatikusan a tárhelyünkön lévő drupla rendszereket és a tulajdonosnak szólunk, hogy a drupalja biztonsági kockázatot jelent.

Majd felkínáljuk neki, hogy ha Ő nem tudja frissíteni, akkor ajánlunk neki szakembert. Valakit közületek.

Úgy gondolom, hogy az adatbázis ellenőrzése jó módszer, mert a Joomla és a Wordpress esetén működik. A drupálnál ezt hogyan lehetne megoldani?

Sajnos nincs kapacitás könyveket átolvasni és valószínű minden modult sem lehet ellenőrizni, viszont egy köztes és elég jó megoldásra kell törekednünk. Reméljük, hogy ebben tudtok segíteni.

0
0
domainflotta képe

Ez nagyon gyors volt. Úgy látom pörög a közösség. Büszkék lehettek ilyen aktivitásra.

1, Megnéztem, de nekünk ez nem jó, mert azt kellene tudni, hogy milyen verziót használ a user.

2, Ez már egy jó megoldás lehet.

Igazából tudunk fájlokat is vizsgálni, de eddig szinte mindegyik CMS rendszernél elég volt az adatbázist, ezért ha van megoldás arra, hogy az adatbázis alapján megállapítsuk a verziót, akkor ahhoz ragaszkodnék. Ha nincs megoldás, akkor foglalkoznánk a fájlok vagy a HTTP header vizsgálatával.

1
0
Illyés Edit képe

Én nem tudok róla, hogy az adatbázisból nagy biztonsággal meg lehetne állapítani. Az includes/bootstrap.inc-ben van definiálva a fájlrendszer verziószáma.

2
0
hron84 képe

A legtobb felhasznalo nem torli ki a kapcsolodo fajlokat a Drupal konyvtarabol, igy megoldas lehet a CHANGELOG.txt megnezese, altalaban a legelso bejegyzes az aktualis Drupal verzio kiadasi megjegyzese. Ezt osszevetve a drupal.org -on talalhato aktualis verzioszammal, el lehet jutni bizonyos kovetkeztetesekre.

Persze ez kozel sem szazszazalekos megoldas, de talan egy lepessel kozelebb visz.

Meg egy lepessel kozelebb vihet a modulok .info fajljanak ellenorzese. Ezekben (mar amelyik modul a drupal.org -rol van) szinten megtalalhato az illeto modul aktualis verzioszama, es szerintem a drupal.org biztosit valami api-szeruseget, amivel ez szinten lekerdezheto (vegulis a drush is igy mukodik).

Amiert en nem drush-t valasztanek erre a feladatra, az az, hogy egy oldal sokfele szempontbol lehet torott, es kozel sem biztos, hogy barmilyen drush parancs lefut az adott oldal gyokeren. Ezen felul a tapasztalatok azt mutatjak, hogy a drush kimenete varatlanul megvaltozhat, ezt parzolni szinten nem egyszeru, es hibakra ad lehetoseget.

Szoval ha csak a verzio ellenorzes a cel, en errefele indulnek. Persze, az is elmond valamit az illeto oldalrol, ha a drush mindenfele random hibakat dobal es errorral lep ki, de ehhez az is kell, hogy vilagos legyen a cel, amit el szeretnetek erni: azt szeretnetek tudni, hogy elavult-e az oldal, vagy azt, hogy kompletten rossz.

1
0

--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.
Illyés Edit képe

Sk8erPeter képe

Az még önmagában megoldható lenne, hogy egyetlen Drupal verziószámát lekérdezzük egy PHP-scripttel, úgy, hogy a DRUPAL_BOOTSTRAP_CONFIGURATION fázisban inicializáljuk a Drupalt, majd a definiált VERSION konstans értékét megnézzük.
A probléma az, hogy úgy emlékszem, ez a konstans csak 6-ostól van meg (de korrigáljatok, ha korábban is létezett).

Lásd a bootstrap.inc fájlt:

http://api.drupal.org/api/drupal/includes%21bootstrap.inc/7

define('VERSION', '7.16-dev');

Az viszont már problémát jelent, hogy runtime-ban meg kell határozni az aktuálisan vizsgált Drupalnál a DRUPAL_ROOT konstanst, és ezt majd később felül kellene tudni definiálni, ha pl. az ügyfelek Drupaljain egy ciklussal kellene végigmenni. Plusz ugye a VERSION konstanst is felül kellene tudni definiálni ilyen esetben, mert minden ügyfélnél más-más lehet.

Ezért kerülő megoldás lehet, ha mondjuk az aktuális Drupal-könyvtárat argumentumként adjuk be egy PHP-scriptnek, ez a script megkapja ezt, ez alapján dolgozik, megvizsgálja az adott könyvtárat, majd végez. Ezt a scriptet pedig ciklikusan futtathatná egy akármilyen shell script vagy batch script.
De ez csak egy gyors ötletelés, és valószínű, hogy így sem feltétlenül teljesértékű megoldás - pl. ha korai verzió, nem biztos, hogy létezik a VERSION konstans; de ez persze egyben egy szűrő is lehet, ha túl régi változat (if(!defined('VERSION')){ /* túl régi... */ }).

Az alábbi kód útmutatást adhat kezdetnek, természetesen annyiban módosítani kellene az előbb leírtaknak megfelelően, hogy a $drupal_root_directory változó a command line-tól kapott valamelyik argumentummal (http://php.net/manual/en/reserved.variables.argv.php) lenne egyenlővé téve.

  1. <?php
  2.  
  3. $original_cwd = getcwd();
  4.  
  5. $drupal_root_directory = 'd:\Projects\web\PHP\drupal-7-another\htdocs';
  6.  
  7. chdir($drupal_root_directory);
  8.  
  9. define('DRUPAL_ROOT', $drupal_root_directory);
  10.  
  11. require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
  12.  
  13. if(defined('VERSION')){
  14. echo 'A telepített Drupal verziószáma: '.VERSION;
  15. }
  16. else{
  17. echo 'A VERSION konstans nem létezik, így abból nem meghatározható a verziószám.';
  18. }
  19.  
  20. chdir($original_cwd);

============

Szerk.:
most látom, hogy a VERSION konstanst már említette előttem Illyés Edith.
A fentire kapott -1 szavazat okára kíváncsi lennék, hogy a szavazó szerint mi nem stimmel (igaz, elvileg csak ötletelés zajlik); mindannyian tanulhatnánk belőle (legfőképpen én). Tényleg érdekelne, mi a rossz a gondolatmenetben.

2
-1
domainflotta képe

Köszönöm a segítséget!

Sikerült megoldani a feladatot és most már tudjuk, hogy kinek küldjünk drupal frissítéseket.

A kiküldött értesítőbe szeretnénk rakni tájékoztatást is, hogy milyen biztonsági beállításokat érdemes elvégezni, azonban erre vonatkozóan nem találtam semmilyen leírást a neten.

Joomla rendszerhez már készítettünk egyet:
http://domain.domainflotta.hu/joomla-biztonsag

Tudtok abban segíteni, hogy hol találok leírást a drupalhoz? Persze vannak dolgok, amiket mindenkinek érdemes megcsinálni a biztonság érdekében, de most kifejezetten drupal specifikus dolgok, kiegészítők érdekelnek.

ui.: Úgy vettem észre a drupal a legbiztonságosabb cms, már csak azért is, mert akik használják jobban értenek hozzá, mint pl.: Joomla vagy Wordpress -t használók.

0
0
Sk8erPeter képe

„Sikerült megoldani a feladatot”

Melyik megoldást választottátok?

„Tudtok abban segíteni, hogy hol találok leírást a drupalhoz?”

A zzzinterneten. :) Na jó, bocs, konkrétan mire vagytok kíváncsiak? A hivatalos http://drupal.org honlapon számtalan nagyon hasznos és fontos leírás található, meg nyilván a http://drupal.hu is rengeteg segítséget nyújt (lásd pl. Kézikönyv), de ezenkívül még rengeteg ügyes Drupal-fejlesztő saját honlapját, tutorialjait, beszámolóját is érdemes olvasgatni; a különböző előadásokról készült videókról már nem is beszélve.

Így általánosságban nem lehet megmondani, hogy na EZ lesz az, ami nektek kell, konkretizálva talán több esély van.

0
0
eager képe

...és ha marad rá idő/érdeklődés, akkor esetleg itt is lehet még keresgélni:
http://groups.drupal.org/best-practices-drupal-security

(a kereső kifejezés a hardening drupal és a cracking drupal voltak)

A lényeg valóban, hogy naprakészen kell tartani az installációt.

Ehhez segítség, ha feliratkoztok ennek az oldalnak a tartalmára akár email-hírlevél formában (drupal.org user létrehozásával), akár rss-en keresztül: http://drupal.org/security/

2
0
domainflotta képe

Ezt kerestem. Hála a segítségért!

0
0
domainflotta képe

Sziasztok!

Elkészült a drupal biztonság leírása:
Drupal Biztonság

Kérlek egészítsétek ki, ha valami még eszetekbe jut.

Továbbá...

Várom még azok jelentkezését, akik az ügyfeleink drupal rendszerének frissítését elvégeznék.

0
0
zionduc képe

Most láttam a kezdeményezéseteket a fórumban, és nagyon jó ötletnek tartom, hogy erre is figyeltek!

Legelső észrevétel (nem tudom, hogy más jelezte-e már)
A főoldalatokon alul a Legújabb cikkeknél most rossz a Drupal biztonsághoz tartozó link:
http://www.domainflotta.hu/tudasbazis/idx.php/22/180/Hasznos-segtsgek/ar...
(Bár emellett több törött link is van ott)
A drupal.hu fórumba berakott link jól működik:
http://domain.domainflotta.hu/drupal-biztonsag

4 helyen is a PrestaShop-ra hivatkoztok a Drupal helyett:
A 4., a 8., és a 9. pontokban, és a legvégén a "Ha segítség kell..." résznél.

Az 5. pontban a "Sose telepíts az éles oldaladba "dev" modult." erősnek érzem, mert van olyan, amikor nem tudod kikerülni a dev modulok használatát. Szerintem ha ki van tesztelve az oldaladdal a dev modul, és nem egy olyanról beszélünk, amit tegnap adtak ki, akkor lehet telepíteni.

A 8. és a 9. pontnak ugyan az a tartalma.

A 11. pontban elírások:
"A drupla oldalak" Egyébként ezt én inkább úgy írnám, hogy "Sajnos a drupal oldalak is ki vannak téve a spam támadásoknak" :)
"email ím"

Szintén a 11. pontban:
"Az is egy jó módszer, ha csak regisztrált felhasználók szólhatnak hozzá"
A CAPTCHA akkor is kell, ha csak a regisztrált tagok szólhatnak hozzá.

3
0

Írj rám, ha érdekel a Győri Drupal Használói Találkozó.

Sk8erPeter képe

"Használata sokkal több programozási tudást igényel, mint a többi hasonló CMS rendszeré. Sokkal inkább egy keret rendszer, mint egy önálló honlap."

A Drupal nem keretrendszer (framework), hanem CMS. A kettő nagyon nem ugyanaz!

"De pont a népszerûsége miatt az elsõdleges támadási felület a Hacekereknek és a Spammereknek is. Kiemelt fontosságú tehát, hogy biztonságos legyen, hiszen valódi pénzmozgás történik az oldalon."

Nem minden Drupal-oldalon történik valódi pénzmozgás... Ezt is egy kissé pontosítani kéne.

"A drupal fejlesztõ cég hivatalos biztonsági ajánlásai"

Ezután több pontba szedett lista következik. Hol van ez a hivatalos ajánlás? Egy hivatalos link nem ártana. Rákeresve például sehol nem találok olyan hivatalos ajánlást, amiről Ti beszéltek pl. az első pontban (<FilesMatch "(authorize|cron|install|upgrade).php"> Order deny,allow deny from all Allow from 127.0.0.1 </FilesMatch>).
Valószínűleg azért, mert nincs ilyen hivatalos ajánlás. :) Ha valami tutorialban ez olvasható, az közel sem hivatalos információ.
Valószínűleg a továbbiak nagy része is inkább Drupal-felhasználók által írt javaslatok.

Ami a .htaccess-ben eleve benne van, az az alábbi (7.16, részlet):

  1. # Protect files and directories from prying eyes.
  2. <FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)$|^(\..*|Entries.*|Repository|Root|Tag|Template)$">
  3. Order allow,deny
  4. </FilesMatch>

"web.config fájlt is törölheted, ha nem használod semmire.
xmlrpc.php fájlt is töörlheted, ha nem használsz távoli xml procedúrát."

Ezeknek mi értelme van? Semmi. Ez nem növeli a biztonságot.
SŐT, például a web.config törlése kifejezetten káros, mivel semmi nem zárja ki, hogy valaki költöztetni szeretné a Drupalját Apache-ról IIS-re, aztán esetleg onnan vissza. Ne az legyen az alapfeltételezés, hogy mindenki Apache-szervert használ.
Ezek a törölgetések teljesen értelmetlenek, csak a biztonság hamis látszatát keltik, de pozitív hatásuk nincs, sőt.

"Ne használd az alapértelmezett "admin" felhasználót!"

Milyen „alapértelmezett "admin" felhasználót”? Nem tudok ilyenről; a telepítés során meg kell adni, milyen felhasználónevet fog megadni az illető. Ha az instrukció arra vonatkozott, hogy telepítéskor a felhasználónévnek ne az "admin" karaktersorozatot adjuk meg, akkor valahogy így kéne hangzania. :)

"Meglepõen sokszor történik meg, hogy nem is az alap drupal oldalban van a biztonsági rés, hanem a bõvítményekben, amiket feltelepítettél. Érdemes ezek naprakészen tartani és amiket nem használsz, azokat törölni"

Először disabled-re rakni, utána uninstallálni, majd ezt követően törölni. Volt már pár embernek problémája itt drupal.hu-n is amiatt, mert egyszerűen csak törölte az adott modult, mert nem tudta, hogy előtte le is kéne tiltani, meg uninstallálni. Pedig kell.

"Sose telepíts az éles oldaladba "dev" modult."

Egyetértek az előttem szólóval, ez így önmagában egyáltalán nem igaz: vicces, de előfordul, hogy éppen a "dev" állapotú modul a stabilabb (pl. ha kiderül az elvileg stabil verzió egy gyengesége).

magic_quotes_gpc = 1

Ez miért lenne jó? Az alkalmazás dolga elintézni ezt, a webszerver ebbe ne akarjon beleokoskodni.
Nem véletlen, hogy a Drupal .htaccess fájlban is benne van:

  1. php_flag magic_quotes_gpc off

"titkosított a forráskódja"
Mutathatna nekem valaki olyan Drupal-modult, aminek ilyenje van. :)

1
0
eager képe

Hi, két dolog:

  1. A htaccess körüli tanács (csak 127.0.0.1-ről allow) a madirish.net-es cikkben van, amit feljebb linkeltem ebben a topicban (hozzáteszem, anélkül, hogy alkalmas lennék a benne foglaltak szakmai lektorálására).

  2. A félreértés a "dev" verziójú modulok körül abból a körülményből származhat, hogy a Drupal Security Team ezekhez nem biztosít értesítőket (csak X.Y-1.0-tól kezdődően) (illetve esetleg csak rendhagyó esetben).

    Egészen pontosan: "The development branch of Drupal is not intended for production use. Security problems are fixed, but security announcements are not issued." (CTRL+F → "Which versions are supported" ezen az oldalon.)

    Emiatt én úgy fogalmaznék, hogy lehetőség szerint kerülendő a "dev" verziójú modulok használata, amennyiben azonban mégis alkalmazásra kerül ilyen, akkor a honlap tulajdonosa legyen tisztában vele, hogy a fentiekből eredően lehetséges, hogy biztonsági kockázatot vállal.

0
0
Sk8erPeter képe

  1. Igen, de írtam is, hogy ezzel csak az a baj, hogy az volt a cím, hogy ez hivatalos ajánlás.
  2. Igen, az utóbbi mondatod már teljes körű lenne, így megfogalmazva már sokkal pontosabb a dolog.
0
0
nevergone képe

„A Drupal nem keretrendszer (framework), hanem CMS. A kettő nagyon nem ugyanaz!”

A Drupal nem pusztán keretrendszer és nem csak CMS. Ha ezt a kettőt tekintjük végletekként, akkor a Drupalt középre pozicionálnám úgy, hogy bármelyik irányba kiterjeszthető. Pl. használtam már úgy keretrendszerként a Drupalt, hogy csak az adatbázis-alrendszer kellett belőle és se node-ok, se felhasználók nem voltak.

Kicsit bővebben itt: Mi a Drupal, mire használható?

A fórumtéma indítójának pedig különösen ajánlom még a következő linket, illetve az egész témát is: http://drupal.hu/comment/61939#comment-61939

1
0
Sk8erPeter képe

"használtam már úgy keretrendszerként a Drupalt, hogy csak az adatbázis-alrendszer kellett belőle és se node-ok, se felhasználók nem voltak."

Hmm, érdekes elképzelés, nekem még ilyen nem jutott eszembe, vagy legalábbis nem volt erre igényem. De egyébként érdekelne a dolog, milyen jellegű webalkalmazásnál lehet ez indokolt? Mi az oka, hogy a Drupal által kínált "keretet", függvényeket használod, és nem mondjuk egy más, jóféle, PHP-alapú ORM-et az adatbázis-kezelésre (ha erre a példára koncentrálunk), vagy akár egy tök független keretrendszert, ami a CMS-ek hozzáadott sallangjaitól mentes? Szimpla "megszokás", tehát hogy már jól kiismerted a Drupalt, és ez gyorsítja a munkádat? Vagy más okai vannak?

0
0
domainflotta képe

Köszi ez valóban hasznos volt.

Az, hogy mi a drupal nem célom megítélni, de a cikkben nem javítom, mert így gondolom. Ti vitatkozzatok rajta, ha akartok :)

A szerveren a legtöbb problémát, amit felvetnek megoldottuk, legyen szó a fejlett hibakezelés bekapcsolásáról (http://domain.domainflotta.hu/Fejlett-hibakereses#content) vagy az 500 hibákról.

Az utóbbiról szintén e-mail értesítést küldünk, mert a legtöbben bele se néznek a tárhelyükön lévő error_log fájlba.

0
0
domainflotta képe

Mivel nem értek a drupalhoz marad a nagy G. Az ott talált információkból próbáltam összerakni egy cikket. Miután készen lett írtam, hogy Ti akik értetek hozzá javítsátok, egészítsétek ki. Kérdéseket ne tegyél fel, mert nem tudok rá válaszolni :)

A kivonat:

  1. A pénzmozgásra vonatkozó részt javítottam.
  2. A forrás már nincs meg. Emlékeim szerint a drupal oldalán volt angol nyelven a hivatalos ajánlás
  3. A törölgetést is írták. Önmagában nem érzem problémának. Aki nem apache szervert használ az úgy is jobban ért hozzá és megoldja. Illuziót meg akkor keltene, ha csak ez az egy pont lenne, de azért itt több is van ;)
  4. Ha nem alapértelmezett akkor valóban át kell írni a szöveget. Megtörtént.
  5. Nincs olyan drupal kiegészítő, aminek a forráskódját bármivel (pl.: zend) titkosították? Ha nincs, akkor kiveszem.
0
0
Sk8erPeter képe

"Mivel nem értek a drupalhoz marad a nagy G"
aztán nevergone-nak azt írod:
"Az, hogy mi a drupal nem célom megítélni, de a cikkben nem javítom, mert így gondolom. Ti vitatkozzatok rajta, ha akartok :)"
Ha nem értesz hozzá, miért akarod megmondani róla a frankót? Ha már véleményt kértél, hallgass a tanácsokra. Ne jelents ki valamit, aminek a hátterével egyáltalán nem vagy tisztában.

Ha meg a Google segítségével talált dolgokra hivatkozol, és még forrást sem mutatsz, nehogy már hivatalosnak tüntess fel bármilyen információt, főleg olyat ne, ami nyilvánvaló, hogy NEM AZ. Hiszen éppen te magad mondtad: "Mivel nem értek a drupalhoz marad a nagy G"... A net tele van baromságokat tartalmazó cikkekkel, magukat hozzáértőnek képzelő emberkék tollából. Ne hagyd, hogy a Te oldalad is baromságokat tartalmazzon, teljes magabiztossággal állítva téves információkat.

  1. remek.
  2. Az "emlékeid szerint" nem valami értelmes hivatkozási alap.
  3. Kik írták? És akkor mi van, ha valaki írta? Ki mondta, hogy az helyes információ? Például a web.config törlése kifejezetten ostobaság, attól nem lesz biztonságosabb a rendszered, hogy azt törlöd. Sőt, csak törékeny lesz, mivel így nem lesz költöztethető a rendszer bármikor IIS-re. Példa: valaki a ti szervereteken tartja az oldalát, de mondjuk otthon IIS-t használ. Lemásolja localhostra a cuccokat, amiket fent tart, és nem lesz web.configja, mert te azt tanácsoltad neki. Tök jó, localhoston nem működik a rendszere, jajjjjj, mi lehet a bajjjj? Egyből megy is a kérdés a fórumra. Amiből aztán kijön, hogy egy rendkívül okos cikkben azt tanácsolták neki, hogy törölje ki azt az ominózus fájlt. Mi lesz a konklúzió? "Ne hallgass az ilyen cikkekre." Ez nektek jó?
  4. "A megjelenő felhasználónevet, amúgy is meg tudod változtatni. "
    Ez még mindig nem jó. Nem "megváltoztatni" tudja, mivel az elején MEG KELL ADNI a felhasználónevet (mi legyen a főadmin felhasználóneve??), meg jelszót, tehát legfeljebb valaki szándékosan ADJA MEG ezt a felhasználónevet. Nem megváltoztatja adminról valami másra, mert nincs megadva a főadmin neve, nincs default, mint mondtam.
    "Az esetek 50% -ban ezzel a felhasználónévvel törik fel a Drupal oldalt."
    Milyen statisztika alapján? Ezt is a nagy G mondta? Korábban itt a PrestaShop szerepelt, valaki szólt is, hogy ezt javítsd már, tehát azt egyszerűen csak átírtad Drupalra, és minden rendben, biztos arra is igaz?
  5. Nincs! Nézz körül a drupal.org-on, ingyen letöltheted a modulokat. Ez egyébként is a szabályokba ütközne, mert bárki által módosíthatóvá, továbboszthatóvá kell tenni a kódokat. Egyébként sem "titkosításnak" nevezik szerintem, amire gondolsz, hanem obfuszkálásnak. Nem ugyanaz.
    Még egyébként olyan szabály is van, hogy ugyan lehet pénzért árusítani modult, de hagyni kell, hogy valaki azt módosítsa, újraértékesítse - tehát akár ingyen is megoszthatja. Hogy legalább én hivatkozzak hivatalos információra: http://drupal.org/licensing/faq/#q9 .

Eleinte tök szimpatikus volt, hogy szolgáltatóként próbáltok minél helyesebb és teljesebb információkkal szolgálni a felhasználók számára, de most már úgy tűnik, hogy ragaszkodsz a saját véleményedhez, meg ahhoz, amit "a nagy G mondott". Ez már kevésbé jó hozzáállás, ha már ennyien szánták az idejüket arra, hogy korrigálják az oldalatokon szereplő állításokat.
Ahogy elnézem, amúgy sem sok mindent javítottál azok közül, amiket javasoltunk.

0
0
domainflotta képe

Köszönöm hosszú soraidat. Nyilvánvalóvá vált, hogy konfliktuskereső típus vagy, azonban én nem fogom kielégíteni a vágyaidat. Inkább elhajolok :)

Sajnálom, inkább kötekedésnek tűnik a hozzászólásod, mint értékteremtőnek. Miből gondolom? Nem adsz megoldást, csak problémákat vetsz fel.

UI.: A zend nem obfuszkál, hanem titkosít :)

0
0
Sk8erPeter képe

Sajnálom, ha úgy tűnt, hogy konfliktuskeresés volt a célja a hozzászólásomnak, pedig nagyon nem ezért írtam ennyit. Bocs, ha a stílus esetleg támadó volt, nem ez volt a cél, hanem pusztán szakmai vita. Azért sejtheted, hogy nem rossz szándékból szántam ennyi időt a probléma megvitatására... :) Kicsit félreértelmezted a szándékot (vagy csak valamiért nem szeretted volna elfogadni az ellenérveket).
Azt írod, nem adtam "megoldást", pedig épp azt próbáltam kifejteni, mi a baj a megnevezett pontokkal, mit kellene rajtuk korrigálni. Próbáld meg nem negatívan hozzáállva is elolvasni a tanácsokat. :)
A másik oldalról meg úgy tűnik, nem hajlasz egy ponton túl a segítség elfogadására. Kikérted a véleményünket a cikkedről, én is leírtam a sajátomat, lehet, hogy nyersen fogalmaztam, és ez számodra sértőnek tűnt, de a segítő szándék vezérelt. Szerintem a cikkben pár említett helytelen pont megváltoztatását még egyszer megfontolhatnád.

3
0
domainflotta képe

Köszönöm az észrevételeket. Javítottam a cikket :)

1
0
eMeLA képe

A 11. pontban van jó néhány helyesírási hiba, illetve a kezdő mondat elég félrevezető értelmű: "A drupla oldalak sajnos ki vannak téve a spam támadásoknak..."
Helyette talán: "Minden weboldal ki van téve a spam támodásoknak..."

1
0

...mit tudok: http://web.termuves.hu