Ez nekem kínai, fingom nincs hogy kell felrakni...

Ránézésre nem rossz, de abból a szempontból idióta volt a fejlesztője, hogy a PHP-kódok nyitótagjét teljesen következetlenül egyszer simán <? -vel írta, máskor <?php -vel, pedig a szervereken a short_open_tag nagyon sokszor nincs engedélyezve. Nálam sem volt, így csak akkor sikerült működésre bírnom, amikor kicseréltem az összes <?-t <?php-re mindenhol.
A short_open_tag-et meg szándékosan nem kapcsolom be.
Amúgy a felülete kellemes.

===

(#5101) Telda : hát ebből nem derült ki, hol akadtál el.
Amúgy van test toolja is, amivel lehet csekkolni, a szervered alkalmas-e a telepítésre.
Ja, és előfeltétel, hogy egyáltalán legyen egy webszervered, amin működik a PHP is... (plusz GD library)

[ Szerkesztve ]

Sk8erPeter

Igen, már folyamatban, a testing tool kidobta, hogy a cURL nincs engedélyezve a szerveren, de már írtam a szolgáltatónak .

[ Szerkesztve ]

Amúgy lehet, hogy tök jó, nem vágom, annyira azért nem néztem át, csak meglepődtem, hogy amikor megnyitottam a kezdőlapot, kidobta a forráskódot a short_open_tags hiánya miatt - viszont néhány kód meg "lefutott", mert néhány helyen meg a teljes <?php változatot használták.
Mindenesetre a demója a honlapon elég meggyőző. Ott bekapcsolták a short_open_tags-t.
Végül is ez, amit letöltöttem, ingyenes, mit pattogok má' he'. Meg írták, hogy ennek befejezték a fejlesztését, így hiába is írnék, hogy héló, ezt javítsátok.
A felületén lévő dizájnt viszont érdemes lehet ellopni.

(#5103) Telda : oké.

[ Szerkesztve ]

Sk8erPeter

2010. októberi, az nem volt olyan brutálrég.
Amúgy ez sztem sajnos nem igaz, hogy csak a régi kódokban látni. Egyébként számomra ez a <?= $variable ?> használata is egy okádék, miért nem lehet kiírni azt a nyomorék teljes PHP-taget, meg az echo-t? Sokkal jobban elkülönül. Persze ezek csak költői kérdések.

Sk8erPeter

Itt megjegyezném, hogy a <?= nyitótag 5.4-től kezdve mindig elérhető, függetlenül a short_open_tags értékétől.

A szépsége meg már magánjellegű dolog, én átállok rá, mikor már elég elterjedt lesz az 5.4.

Igen, olvastam a doksiban erről, nekem személy szerint nagyon nem tetszik.
Szerintem nehezebben átláthatóvá teszi a kódot, ha egyértelműen kiírom azt a plusz pár karaktert az echo-val, akkor azzal nem tettem semmi ördögtől valót, viszont legalább azonnal látszik, hogy na ott egy kiíratás van. Amúgy gondolom ASP.NET-ből származik ez a mánia, bár nem értem, mitől jó.
Ízlések és pofonok különböznek, látom ebben eltér az ízlésünk.
Szerk.: hozzáteszem, ez is valószínűleg megszokás kérdése, ha valaki rááll erre, akkor persze nyilván gyorsabban rááll a szeme, de ha már pl. HTML-kódba belepakolok PHP-kódot (valamilyen szintű szemantikai keveredés sok esetben elkerülhetetlen, vagy így egyszerűbb), akkor már miért is ne írhatnám ki egzakt módon, mi is történik.

(#5110) Speeedfire : jaja, persze, azért túlzásokba sem kell esni.

[ Szerkesztve ]

Sk8erPeter

sziasztok!
Akinek van minöségi, lehetőleg látogatott weblapja az keressen meg.
Hírdetés kirakásával elég jól lehetne keresni vele.

Ahhoz nem kell programozni, hogy pontosan dolgozzunk és fogalmazzunk!!

"Olyan nincs, hogy nincs" + www.plenter.atw.hu

templatekingdom.com oldallal van valakinek tapasztalata, élménye? Nekem lett most egy negatív....

Nem ismerem, de ha rossz élményed van vele, akkor próbáld meg ezt. Szerintem elég jók vannak fent.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Köszönöm. Használtam már más template oldalakat is-eddig gond nélkül, de most egy kifejezett kérés jött egy az említett templatekingdom-on fent lévő templatere.

Mi a gond vele?

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Kifizettem, de letölteni nem tudom.

Nem kaptál emailt?

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Voltam olyan bátor, hogy "instant payment"-tel akartam fizetni, előtte külön nem csináltam accountot, nem léptem be. Állítólag fizetés után a letöltő oldalra kellett volna visszairányítani.

Template be a kosárba, majd checkout. Bekérte közben a nevem és az email címem. Ezután fizetés paypallal, lovettát levonta, majd amikor vissza kellett volna irányítani a bolt oldalára, akkor elkezdett tölteni, mintha nem tudná behozni az oldalt, majd "az oldal nem válaszol.." aztán le is fagyott.

Küldtem már egy 5-6 emailt különböző címekre, de nem igazán akarnak válaszolni.

Grátisz:

Felhasználói felületre nem tudok regelni, mert a cím már foglalt. Gondolom elmentette valamikor a folyamat során. Oké, akkor jelszó emlékeztető. Az meg nem jött el.

[ Szerkesztve ]

Remélem nem haragszol meg érte, de te voltál a b*na. Ilyet sosem szabad csinálni. Sok helyen még írják is, hogy előbb acc, belép, fizet.
Pl a godaddy-n is lehet így fizetni, de eszembe sem jutna előre fizetni.
Hát ha szerencséd van akkor a paypal email címed alapján elküldik majd az infókat.

Spamek között nem nézted meg?

[ Szerkesztve ]

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Előrefizetésnek azért nem hívnám ezt. Bíztam benne, hogy hiba nélkül végig megy a folyamat. Nem az a problémám, hogy fellépett egy hiba, hanem az, hogy nem válaszolnak az emailre. Ha nem sikerül a héten megoldani, akkor gyalázkodok egy kicsit minden elérhető külföldi és magyar blog, review, forum oldalon.

...vagy indítasz egy dispute-ot paypal-on (lévén nem kaptad meg amiért fizettél) és annak talán még értelme is lenne.
vagy erre nem lehet?

Szerintem lehetséges.

Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com

Most olvasom végig. Az a baj, hogy nem is voltam belépve paypalre. A pénz nem a paypalomon volt, hanem bankkártyán.

Igen, ezt mondom.
De így mint kártyás vásárlást, nem tudom, hogy vissza lehet-e csinálni.

Gondolkodom egy projecten, illetve annak megvalósításán. Jó lenne, ha webszerveren tudnám tárolni az adatokat - ám mivel az adatok egy része érzékeny -, titkosítva lenne az adatbázisban (MySQL vagy SQLite 3). Nem saját szerverről lenne szó, mely a pincében csücsül, tehát a visszafejtésnek kliens oldalon kellene történnie.
A fent leírt szituációban szerveroldalon PHP-vel nagyjából mindent meg lehetne oldani, de az a kérdés, hogy a titkosított adatok visszafejtését miként lehet megvalósítani a kliensél (pl. írni egy Firefox extensiont?).

Gondolkozom abban is, hogy a felhasználó gépén egy lokálisan futó program lenne, viszont azzal nem tudom elérni a szolgáltatónál lévő adatbázist, igaz?

Ha nagyon hülyeségeket kérdezek, bocs.

Ha az adatokat egy adatbázisszerveren titkosított módon tárolod biztonsági okokból, akkor annak mi értelme van, hogy kliensoldali kóddal fejted vissza az adatokat? Ha kliensoldali kódról van szó (pl. JavaScript), akkor a visszafejtésre szolgáló kód teljes mértékben látható mindenki számára, biztonság nulla.
Azt még meg lehet csinálni, hogy egyik szerveren van az adatbázis (már ha mindenképp fontos a szétválasztás), ahhoz külső hozzáférést engedsz (megfelelő authentikációval férsz hozzá), másik szerveren az első szerverről elérhető adatokat feldolgozod, és ezeket az adatokat szolgáltatod kifelé.

Sk8erPeter

Teljesen homályos nekem ez a terület, ezért zaklatlak titeket, mert azt sem tudom, honnan induljak el. Az lenne a cél, hogy csak a megfelelően azonosított felhasználó láthassa az adatokat. Tehát ha Gipsz Jakab rendszergazda lemásolja magának az adatbázist és a php kódot a szerverről, ne tudja kinyerni az adatokat. Miként lehet ezt megvalósítani?

Azt sem tudom, ha pl. van három felhasználó, miként kapják meg a kulcsot az adatok visszafejtéséhez, mert gondolom csak egy kulcs lehet és azt nem tárolhatom a szerveren.

Mellékvágány: a jelszavakat pl. SHA()-val tárolni, elvileg az sem kellene hogy (könnyen) visszafejthető legyen, ugye?

Szóval nagy a kavar a nálam, nem ismerem, milyen lehetőségek vannak a megoldásra.

Az adatbázisnál oké, hogy titkosítva tárolod, hogy ránézve az adatokra, abból a rendszergazda ne tudjon semmit sem értelmezni (ergo számára használhatatlanok ebben a formában az adatok).
A PHP-kódot meg obfuszkálhatod valami jóféle szoftverrel, így elég nehezen fog rájönni, hogy mi az algoritmus az adat visszafejtésére. Tehát a fejlesztői kód nem kerül fel erre a szerverre, csak a jól összekutyult, értelmezhetetlen kód. Az obfuszkált kód deobfuszkálása meg többnyire annyira nem hatékony, hogy elég nagy valószínűséggel borítékolható, hogy ezt inkább feladja az illető, aki próbálkozik.

Ha adatokat akarsz titkosítani, pl. infók: [link] >>> [link].

Jelszótárolásra meg bővebb irományok: [link].

Sk8erPeter

Kösz, ez hasznos volt.
Most 2 utat látok:
1) az adatok titkosításához a szerveren tárolok egy "nyers" kulcsot, amit egy obfuszkált php kódban -dinamikusan - több változóból összeállított unique salt+hash-sel készre faragok, amikor hitelesítésre kerül a felhasználó.

2) egy elképzelés: a kliens gépen zajlana a dekódolás pl. FF extension segítségével - már ha ez megoldható egyáltalán. Előnye, csak az tudja dekódolni az adatokat, akinél telepítve van az extension, mivel 2 külön helyen van a titkosított adat és a hozzá tartozó kulcs. Hátránya, lövésem sincs, kivitelezhető-e, ill. mennyire terhelheti (csökkentheti a felhasználói élményt) a kliens oldalt.

Vélemény?

Most látom, PHP tudja az openssl-t is, hmmmm.

1. konkrétan nem tudom, milyen adatokra gondolsz. Ha csakis a jelszó lenne az érdekes, amit szeretnél elrejteni mondjuk egy rendszergazda elől, aki hozzáfér az adatbázishoz, akkor olyan nagyon nem érdemes túlmisztifikálni, egyszerűen egy hash-elt változatát tárolod el a jelszónak adatbázisban (így ezzel nem tud mit kezdeni az sem, aki hozzáfér az adatbázishoz), és amikor a júzer próbál bejelentkezni, akkor az általa beírt jelszónak ugyanazt a hash-ét előállítod, és megvizsgálod, egyezik-e az adatbázisban tárolt hash-sel. Ez nem visszafejthető, csak az egyezést tudod vizsgálni.
Ha már komplexebb adatokat akarsz tárolni titkosítva, és azt vissza is szeretnéd fejteni valami értelmes módon, emberi időben, akkor az már más tészta, ott egy szimpla hash-elés nem lesz jó, mert azt nem fogod tudni visszafejteni, tehát valami egyedibb algoritmust kell kitalálni arra, hogy hogyan tárolod, és mi lesz a visszafejtés módja. Adott esetben ez elég bonyolult is lehet, ha nem szeretnéd könnyen feltörhetővé tenni.
Amúgy nem tudom, milyen adatokról lenne szó, de ezt azért érdemes átgondolni többször, hogy biztos érdemes-e belevágni a komplex algoritmus kitalálásába.

2.) extension titkosított adatok dekódolásához? Nem jó ötlet. Az extension kódjába bele tud turkálni más is, szóval magyarul akkor semmi értelme a kódolásnak, a dekódoló algoritmushoz úgyis bárki hozzáfér. Ergo saját céljaira is onnantól kezdve fel tudja használni, tehát mintha nem is titkosítottál volna semmit - ezenkívül meg kell oldani, hogy valami web service-en keresztül szolgáltass adatokat; ha itt authentikációra is szükség van, akkor az ahhoz szükséges adatokat is bele kellene drótoznod az extensionöd kódjába, tehát akkor a felhasználó böngészőjére telepített extensionben igazából bárki megtalálja a szükséges infókat.

Sk8erPeter

Az már elveszhetett a sok dumá(m)ban, amit az elején írtam, hogy az adatok egy része szenzitív. Tehát komplexebb adatokról lenne szó.

Ha illetéktelen hozzáfér a böngészőhöz, az már nem az én bajom, mindenki óvja a gépept, ahogy tudja. De piszok vagyok.

Esetleg még az jutott eszembe, hogy pythonban megírni a kliens oldalon futó programot (helyileg futó alkalmazásként), ami a szerveren futó PHP script segítségével olvassa/írja az adatbázist, az adatok már titkosítva mozognának, csak a kliens oldalon lenne titkosítás/visszafejtés. Mondjuk sem pythonban, sem PHP-ben nem tudom, miként oldható meg ez a kommunikáció, de erre van a doksi. Valószínűleg egy darabig olvasgatni fogok, de legalább van valami értelmesnek tűnő megoldás.
Vagy van más mód hozzáférni egy webszerveren levő adatbázishoz?

Anyám, ha én ebből egyszer működőképes cuccot faragok...

[ Szerkesztve ]

Hogy jön a képbe a Python? Most nem mindegy, hogy PHP-ben írod meg vagy Pythonban? Mindkettő scriptet tudni kell futtatni valahogyan...

"Ha illetéktelen hozzáfér a böngészőhöz"
Mi va'? Ezek szerint nem értetted, amit írtam. Az extension kódjához fér hozzá bárki. Értsd: valaki átküldi az extensionjét egy ismerősének, aki látott már valaha programkódot, az már némi kódtúrkálás után vágja is, mivel "dekódolod" az üzenetet, látja a hozzáférési adatokat a szerveredhez, és így tovább... Nem tudom, világos kezd-e már lenni, hogy bárkihez kerül is az extension, akkor az már könnyűszerrel tudja leszedegetni az adatokat a szerveredről, amennyiben van némi fogalma róla, hogy mi is lehet onnan érdekes.

Egyre inkább úgy tűnik, hogy neked inkább valami asztali kliensalkalmazást kéne inkább létrehoznod ehhez, szerveroldalon meg egy web service-t, de semmiképp sem extensionnel kéne "dekódolnod".

[ Szerkesztve ]

Sk8erPeter

Hogy jön a képbe a Python?
Mint asztali kliensalkalmazás.

Ezek szerint nem értetted, amit írtam.
Dehogynem. csak továbbléptem.
Igazából nem tudná, vagy legalábbis nem könnyen, mert először be kellene jelentkezni, hogy kapjon adatokat. A bejelentkezés meg nem az extension-ön keresztül menne.

szerveroldalon meg egy web service-t
Na, erre lennék kíváncsi. Ez mit jelent?

[link]

Sk8erPeter

Ez azt jelenti, hogy kell egy virtuális szerverre előfizetni, amin pl. Apache Tomcat fut?

Dehogyis....
A Tomcat server Java-s alkalmazásokhoz van elsősorban.
A web service nincs nyelvhez kötve. Pl. SOAP-szervered lehet C#-ban és PHP-ben is megírva (vagy Java-ban, és így tovább)... (épp nem olyan rég beszéltünk a PHP topicban az ilyen jellegű SOAP-ásokról ).
A PHP-s megoldásról itt van pl. egy cikk: [link].
Én is szívtam régebben komplex adatszolgáltatással PHP+NuSOAP segítségével, amihez C#-klienssel (asztali alkalmazással) kapcsolódtam: [link].

[ Szerkesztve ]

Sk8erPeter

Kösz szépen, sokat segítettél, asszem el fog tartani egy darabig, amíg mindezen átrágom magam...

stackoverflow: jópofa kutyus

Nincs mit, ja, és előbb elfelejtettem egy lényegeset beleírni végül a hozzászólásomba, hogy szervertől sem függ a webszolgáltatás. Tehát lehet egy általad említett Tomcat szerveren egy Java-s webszolgáltatás, lehet Apache-on egy PHP-s webszolgáltatás, vagy lehet IIS-en egy C#-os webszolgáltatás, és még sorolhatnám. A lényeg, hogy egy kliens alkalmazással csatlakozol a webszolgáltatást biztosító szerverhez (esetleg megfelelő authentikáció után, amennyiben szükséges, de van, ahol elérhető egy webszolgáltatás úgy is, hogy nincs szükség felhasználónévre és jelszóra, hanem anonimként is használható!), amelyik megfelelő metódusokon keresztül adatokat szolgáltat, bizonyos elvárt adattípusok formájában.
Pl. SOAP esetén van egy WSDL-fájl (Web Services Description Language), ami lényegében egy leírás az elérhető metódusokról, az elvárt bemeneti és kimeneti paraméterekről (azok típusáról, stb.), namespace-ekről, egyebekről...ez egy szabványos leírás, ezért nagyon sok kliens azonos módon tudja értelmezni ezeket az adatokat.

Csak egy példa, hogy mondjuk egy web service-en keresztül egy asztali alkalmazással egy, a neten elérhető szerverről lekéred a webshopjukban elérhető terméklistát, plusz a termékekhez tartozó árakat, leírást, stb... Ez tehát egy kényelmes módja lehet meghatározott adatok bizonyos interfészen keresztül történő szolgáltatásának.

Sk8erPeter

Most alapvetően, ha egy normális szolgáltatót keresel, akkor igenis komoly jogszabályok és titoktartási kötelezettségek vonatkoznak rájuk, még ha véletlenül bele is néznek a DB-be.
De egyébként teljesen valószerűtlen a dolog, hogy most a rendszergazda vagy akárki elkezdi olvasgatni az adatbázisodat, szvsz.

Bár nem kötözködéből, de tényleg kíváncsi lennék milyen típusú adat, amit ennyire féltesz?

- http://pazsitz.hu -

Teljesen mindegy, mi vonatkozik rájuk, mindig van ember, aki pénzért vagy más előnyért (esetleg szórakozásból) bármire hajlandó.

Milyen típusú adatok? Pl. személyes azonosító adatok, bankszámlaszámok stb.