ugrás a tartalomhoz

Weblap - IntoMusic - vélemény kérés

vmarci21 · 2016. Aug. 1. (H), 19.29
Sziasztok,
szeretném bemutatni, és véleményt kérni a következő weboldalamról.
intomusic.hu
Köszönöm ;)
 
1

Egész jó

Pepita · 2016. Aug. 2. (K), 18.20
Design-ra én nem mondok semmit, nem értek hozzá, kinézetre nekem bejön. (Bár a slidert én nem csípem, de divat)
<meta name="description" content=""> nincs kitöltve, ez SEO hiba.
Pár helyen szerepel <div class="slider" style="background:#c0392b;"> inline style, ettől tartózkodni kéne, főleg ha van is rajta class attribútum.

Nem túl szerencsés angol és magyar elnevezéseket keverni:
<a href="/assets/belep/social.php?mibe=google" ...
Idővel nem fogod tudni, hogy az adott dologra most angolul vagy magyarul kéne hivatkozni.

Tartalom / szolgáltatás:
- Elsőre az jön le, hogy ugyanazt próbálja nyújtani, mint sokan mások is - semmi okom rá, hogy váltsak. (meg is kell győzni a látogatót, hogy használja pl. a Deezer helyett: írd le, hogy miért jobb a tiéd mindegyiknél.)
- Rólunk: ez inkább külön oldal lenne, ott viszont jóval részletesebb. Egy "cég" (szolgáltatás) 2 éve ha leírható 2 mondatban, akkor ott senki nem csinált semmit.

Az IntoMusic ingyenes, és az is marad!
Nem kérünk pénzt, és nem korlátozzuk a zenelejátszást!
Lehet, hogy én vagyok szkeptikus, de nekem erről rögtön az a kérdés került elő, hogy "OK, de akkor mi az, amiért neked megéri vele foglalkozni?" És mivel ez megválaszolatlan, máris bizalmatlan vagyok, mert ki tudja, hogy holnap működni fog-e.

Kövess másokat, és osszd meg velük kedvenc zenéidet!
Hozd össze ismerőseidet, és fedezz fel új dalokat!
Így magában ez nem mond semmit.

Backend-ből nem láttam semmit, engem inkább az érdekelne.

Ha túl kritikus voltam, akkor ne törődj vele, az a szándék vezérelt, hogy amennyiben akarsz rajta javítani, akkor adjak pár tippet, hogy hol érdemes.

SZERK.: osszd - Hozd. Sanszos, hogy a kettő közül az egyik helyesírási hiba.
2

Köszi

vmarci21 · 2016. Aug. 2. (K), 20.15
Hello, köszi a hosszú üzenetet.
meta-t javítottam, inline style-k javítása is tervben. ;)
URL-ben az angol és a magyar nyelvnek a keveredésének az oka, hogy jelenleg próbálom a régi magyar URL-eket angolra cserélni, és még nincs mindenütt cserélve - bár a fontosabb (átlagfelhasználók által látott) linkek nagy része Angol. ;)

Szolgáltatás terén tulajdonképpen 2015-ig az egyetlen konkurenciája a bop.fm volt, de azt - ha jól tudom felvásárlás miatt - megszüntették. Igaz ismerek még 2 kisebb oldalt, de azok csak 3 oldalról támogatják a lejátszást (SoundCloud, Deezer, YouTube), míg az IntoMusic 14 oldalt is támogat (na jó, Spotify támogatása elég részleges..)
Éppen ezért az oldal az általad említett Deezer-nek pl. nem konkurenciája, hiszen pont arra épül. Hogy miért jó az egész? Ennek egy rövid története van:
Az egész úgy kezdődött, hogy a zippyShare-ról való zenelejátszást nem találtuk túl kényelmesnek - mivel hogy a gyári lejátszó a play/pause-n kívül tulajdonképpen semmit nem tud - így felvetődött az ötlet egy lejátszó-oldal létrehozásán (IntoMusic 1.0). Majd később előjött az az ötlet is, hogy milyen jó lenne, ha a sok oldalon elérhető tartalmakat ehhez hasonló módon egy oldalon lehetne elérni, a jelenlegi sok helyett (2.0-s verzió). Később ez bővült azzal, hogy jó lenne a saját, felhőben lévő tartalmak (oneDrive, Google Drive stb.) elérését is megcsinálni.
(Utlosó, Backend-es érdeklődésedre:) Fejlesztés közben nagyon sok dolog felmerült a szolgáltatással kapcsolatban, 2.0 megjelenésével tulajdonképpen újra kellett építeni a teljes adatbázis-szerkezetet, és zenekereső rendszert, annyi duplikáció került a rendszerbe, illetve a sok tartalomnál a sima listázás felhasználói részről áttekinthetetlen lett, így alakult ki a most látható toplista oldal. Ezeken kívül pedig a különböző API-k rendezése, adatainak feldolgozása (különböző adatok, mégis meg kell találni a megegyező zenéket) és ezek használata mellett is normális oldalbetöltési sebesség elérése volt talán a legnehezebb feladat.
</story>

Tehát vissza az oldal szolgáltatásaira: Az oldal célja az, hogy megszüntesse azt az összevisszaságot, hogy - a legnépszerűbb tartalmakat kivéve - tulajdonképpen semmi sem érhető el egy szolgáltatás alatt, ezért ez az oldal segít a lehető legtöbb forrásból tartalmazó zenéket mégis egy lejátszóba "összehozni". (Ezt próbálja meg bemutatni a főoldal, úgy tűnik, még változtatni kell rajta, pl. egy részletesebb leírás hozzáadásával. ;))

Mi garantálja, hogy holnap is leérhető lesz az oldal?
Tulajdonképpen semmi, a Grooveshark vagy a bop.fm (hogy témába illő oldalakat hozzak fel) is megszűnt egyik napról a másikra, pedig milliós látogatottságuk volt előtte több éven át. Mondhatom, hogy nem fogom megszüntetni az oldat, de ki hinné el nekem? (Egyébként tényleg nem tervezem a megszüntetését :D ;) )

Hogy miből él meg az oldal?
Terveim (inkább reményeim) szerint az oldalon megjelenő hirdetések néhány éven belül vissza fogják hozni az oldal üzemeltetésének árát. De ha mégsem, akkor sincs baj, mert én is az oldal felhasználója vagyok, és napi rendszerességel használom, és amíg nincs alternatívája, addig ez így is fog maradni.

A SZERK részben leírtakat sajnos nem teljesen értem, nem tudom, mire írtad ezt. ;)

És még egyszer köszi a visszajelzéseket. ;)
3

van még olyan, hogy

szabo.b.gabor · 2016. Aug. 2. (K), 21.33
van még olyan, hogy audiosplitter. az is ilyesmi. az oldalad azért jobb, mert linugz alatt kevesebb erőforrást kér, úgyhogy királyság. :)

nekem most hirtelen csak ennyi, hajrá!
4

Van még :)

Pepita · 2016. Aug. 3. (Sze), 08.40
A szerkesztett rész részletesen:

Kövess másokat, és osszd meg velük kedvenc zenéidet!
Hozd össze ismerőseidet, és fedezz fel új dalokat!
Ebből az első félkövér szó egy "sz"; mivel ez a két mondat (szó) egy frame-en van, rögtön szembetűnt, hogy ugyanaz a helyesírási szabály vonatkozik rájuk, így az egyik biztosan helytelen. Segítség:
„osszd”: ismeretlen
Javaslatok: ossz, oszd, osszad, ossza

Description jó lett, szerintem a title is lehetne kicsit több, pl "IntoMusic - minden zene egy helyen".

Regisztráció form:
- Belépni hol lehet, ha már regisztrált valaki? Belépés formot nem látni sehol.
- Ezt egy kicsit jobban meg kéne fogalmazni, első és utolsó szó ismétlés:
Belépéshez az IntoLogint használhatod, így az intomedia.hu, into.hu, kewix.hu, shop.into.hu, music.into.hu oldalon használt adatokkal, vagy a lentebb látható közösségi belépési lehetőségekkel tudsz belépni.

- Én úgy tudom, hogy amennyiben bármiféle ÁSZF jellegű dolgot el kell fogadni a regisztráláshoz / használathoz, akkor azt ott helyben, ahol be kell pipálni, be is kell linkelni. Így hirtelen nem is láttam "az Into.hu és az IntoMusic szabályzatát." sehol.
- Nem fogadta el a "+" jelet e-mail címben, pedig lehet benne.
- Sikertelen regisztráció után elveszett az összes megadott adatom a formból.
- Sikeres reg után beállítások -> színséma - kék: szétesett az oldal, mintha nem lenne css. F5 után helyreállt.
- Nincs jelszó megerősítése. Ez azért fontos, hogy megvédd a user-t, ha véletlen elgépeli. Akkor nem lesz egyforma a kettő.
- Belépés után már látható némi ÁSZF, van is benne helyesírási hiba:
... erre az oldalra is vonatkozik, melyet itt olvashatja el.
.. melyet itt olvashat el.
De nem szerencsés az "itt típusú" link, mert ha valóban itt, akkor nem kell linkelni, mert helyben vagyunk... :)
- Kilépés után az /en-en URI-ra irányított, előtte hu-hu volt. Amúgy mi célt szolgál a duplikált nyelvi kód? Azon túl, hogy csúnya (és nem is kéne URL-ben lennie, session / cookie simán alkalmas rá).
- Nincs e-mailes aktiválás: akár másvalakiét vagy nem létező címet is megadhatok.

Apropó, sütik.. PHPSESSID nem szerencsés név... És az id-t is jobb magadnak generálni, és sűrűn cserélgetni. Az ördög nem alszik.

Ha nem titok, kíváncsi lennék régi és új db szerkezetre.
Ha teszel ki valami login formot, akkor majd még tesztelném, pl biztonságra, míg le nem tiltasz. :)
Aztán lehet, hogy pár "nótát" is meghallgatnék, "hátha itten jobban zeng".
5

Így már érthető, javítottam

vmarci21 · 2016. Aug. 3. (Sze), 09.40
Így már érthető, javítottam az elírást ;)

- Menüben ott a belépés gomb. Kapott kiemelést. ;)
- emailban a + jelet már a HTML5 is visszadobta, vagy csak a PHP?
- színtéma választás hibát nem sikerült reprodukálnom... JavaScript hibát nem kaptál véletlenül?
- Szabályzatot javítottam, kiegészítettem.
- URL-ben a nyelvi kódok a keresők miatt vannak, hogy minden nyelven megtalálják az oldalakat. Kilépés után minden törlődik session-ból, így az is, hogy milyen nyelven böngésztél addig, így automatikusan a böngésző által küldött adatokból állapítja meg a nyelvet, ha az URL-ből hiányzik. Azért látszik duplikáltnak, mert az első az oldal-nyelv, a második a régió beállítása. (tehát angol esetén lehet en-us, en-au, en-gb is... , pont úgy, mint a www.microsoft.com/hu-hu oldalon is pl.)
- PHPSESSID név helyett miért jobb más?
6

Szia, OFF, de talán mégsem,

smokey · 2016. Aug. 3. (Sze), 10.22
Szia,

OFF, de talán mégsem, és a Session szóról jut eszembe: Ha sok felhasználót vártok, és egyszer csak lekönyököl a szerver, akkor mi módon tudtok skálázni?

A session itt azért jön szóba, mert ha később valamiféle loadbalancigot kell alkalmazni (tehát több szerverről kell kiszolgálni a rendszert) terhelés miatt, akkor lehet kicsit gondban lesztek, mert ha X szerveren elindul a felhasználó sessionje, és a következő kérés mondjuk Y szerverre érkezik, akkor ott az előző session nem fog létezni; bár van erre is megoldás, hogy ne legyen nagy probléma.

Web service-en keresztül ajánljátok ki a rendszer működését (pl.: REST API)? Mert ha igen, akkor ott érdemes stateless maradni, vagyis a session használatát mellőzni, így könnyeben tudtok horizontálisan bővíteni.

Milyen keretrendszert használtok?
7

Felejtős

Hidvégi Gábor · 2016. Aug. 3. (Sze), 13.14
Tipikus előre optimalizálás esete, és csak akkor kell foglalkozni vele, ha tényleg van terhelés. Mi van, ha sosem jön be a dolog? Akkor kidobott idő, amit ezzel tölt.
8

Az a tapasztalatom, ha

smokey · 2016. Aug. 3. (Sze), 13.31
Az a tapasztalatom, ha kapásból így áll neki az ember, akkor a munkavégzés is lehet gyorsabb, hatékonyabb. Főleg ha más ember dolgozik a backenden, mint a frontenden. Nem csak a terhelés miatt érdemes egyébként szétválasztani a rétegeket, jobban elkülönülnek rétegek szerepkörei is; és nem történik olyan, hogy egy HTML fájlban írodik meg egy "SELECT * FROM".
9

Skálázás

Hidvégi Gábor · 2016. Aug. 3. (Sze), 13.45
A skálázásra utaltam az előbbi hozzászólásomban.
10

Értem; attól függetlenül, ha

smokey · 2016. Aug. 3. (Sze), 14.36
Értem; attól függetlenül, ha a rétegek rendben vannak, akkor már kvázi felkészült a rendszer a skálázásra.
13

Hogyan?

Hidvégi Gábor · 2016. Aug. 3. (Sze), 19.57
Nem igazán látom az összefüggést a rétegek, a munkamenet és a skálázódás között, kérlek, fejtsd ki.
16

Tehát. Tegyük fel, hogy úgy

smokey · 2016. Aug. 4. (Cs), 08.26
Tehát. Tegyük fel, hogy úgy állsz neki a rendszer lefejlesztésének, hogy csinálsz egy restful backendet, pl PHP nyelven; az fut egy szerveren. Ehhez tudsz csinálni több klienst, pl egy böngészőben futó tiszta HTML, CSS, JS alapú klienst; ez is fut egy másik szerveren.

Ha a backend és a frontend ilyen módon szét van választva, akkor a rétegek már viszonylag jól karbantarthatók.

Az is igaz, hogy egy ilyen backend esetében nem árt, ha stateless-ek maradunk, tehát nem használunk munkamenet.

Szerintem ezen a ponton még nincs többlet munka.

Ha a rendszer terhelődik, mert ügyes volt mindenki és gyűlnek a felhasználók, akkor ezt az architektúrát már egyszerű skálázni, mégpedig azért, mert a backendet annyi szerveren tudjuk még üzemeltetni, amennyin kell (vagy csak növeljük az instancek számát amazonban :)); plusz a stateless megoldás miatt sem kell aggódni a sessionök miatt.

Próbáltam röviden összeszedni a gondolataimat, és leírni az általam vélt összefüggést a három említett fogalom között. Ha így sem érthető, akkor megpróbálom másképp, mégegyszer.
18

Még mindig nem áll össze a kép

Hidvégi Gábor · 2016. Aug. 4. (Cs), 08.56
A szerveroldali PHP és a kliensoldali HTML minden esetben szétválik, ezért továbbra sem értem, hogyan kapcsolódik ez a skálázódáshoz.

Szép dolog az állapotmentesség, csak nem mindig oldható meg a fenti architektúrával, már a legegyszerűbb boltnál is a kosárkezelés felhasználónként egyedi.

Attól függ minden, hogy mi a backend kimenete.
20

A szerveroldali PHP és a

smokey · 2016. Aug. 4. (Cs), 09.04
A szerveroldali PHP és a kliensoldali HTML minden esetben szétválik, ezért továbbra sem értem, hogyan kapcsolódik ez a skálázódáshoz.


Jobb esetben igen, viszont ha kiindulsz pl egy Joomla, vagy egy WP oldalból, akkor tudhatod, hogy a HTML kódot is ugyanaz a PHP alkalmazás generálja ki, ami az adatbázis műveletekért is felelős.

Szép dolog az állapotmentesség, csak nem mindig oldható meg a fenti architektúrával, már a legegyszerűbb boltnál is a kosárkezelés felhasználónként egyedi.


Az állapotmentesség nem zárja ki a biztonságos felhasználókezelést.

Attól függ minden, hogy mi a backend kimenete.


Itt mire gondolsz pontosan?
23

ha kiindulsz pl egy Joomla,

Hidvégi Gábor · 2016. Aug. 4. (Cs), 16.48
ha kiindulsz pl egy Joomla, vagy egy WP oldalból, akkor tudhatod, hogy a HTML kódot is ugyanaz a PHP alkalmazás generálja ki, ami az adatbázis műveletekért is felelős.
Ezt nem látom problémának, mert Magyarországon a legtöbb weboldalnál ez bőven megteszi. Ahhoz már nagyon nagynak kell lenni, hogy ennek a szétválasztásnak az árát átlagos eszközökkel megérje kifizetni a megrendelőnek.

»Attól függ minden, hogy mi a backend kimenete.«
Itt mire gondolsz pontosan?
HTML kimenetre.
21

van egy boltod, tegyük fel,

szabo.b.gabor · 2016. Aug. 4. (Cs), 11.22
van egy boltod, tegyük fel, hogy session-ben tárolod a kosár tartalmát, van egy olyan kérésed, hogy
[GET] /api/kosar

ez visszaadja a kosarad tartalmát.
ez volna a nem állapotmentes verzió, mert attól függően, hogy ki hívja a kérést, más kimenetet ad.

nehezebb széttolni több szerverre, mert vagy kell valami session szinkronizáció, vagy sticky session kell.

lehet persze a kosár adatbázisban is (persze az előző verzió esetén is, és mondjuk a kosár id van csak a sessionben tárolva, de a session szinkronizáció akkor is probléma), és a kosár tartalmát kérdezheti a kliens úgy is, hogy
[GET] /api/kosar/1232314

ez volna az állapotmentes verzió, itt már könnyebb széttolni több szerverre a dolgot, mert lehet a php alatt is több szerver, de az adatbázis is széttolható több szerverre.

persze ettől még az állapotmentes kérés esetén is mehet egy cookie-ban (vagy inkább valami speckó headerben és akkor a hijack ellen is védetebb) valami token, ami azonosítja az adott felhasználót, ennek segítségével db-ből megkapjuk ki a júzer, és ha tudjuk hogy ki, akkor már azt is tudjuk ellenőrizni, hogy van-e jogosultsága hozzáférni az adott kosár lekéréséhez..

és viola (direkt írtam el), session nélkül működünk, könnyen skálázódunk.
22

Jó a levezetés/átvezetés!

smokey · 2016. Aug. 4. (Cs), 13.44
Jó a levezetés/átvezetés! Egyébként JWT-vel dolgozunk, elég jó, és pont erre lett kitalálva.
24

(...) nehezebb széttolni több

Hidvégi Gábor · 2016. Aug. 4. (Cs), 16.58
(...) nehezebb széttolni több szerverre, mert vagy kell valami session szinkronizáció, vagy sticky session kell
A loadbalancer egyszerűen meg tudja oldani, hogy egy felhasználót mindig egy szerver szolgáljon ki, így jóval egyszerűbb alkalmazáslogika és szoftverarzenál szükséges a munkamenetek kiszolgálásához.

Értem, amit mondotok, viszont átlagos eszközökkel ezek több problémát vetnek fel, mint amit megoldanak. Jó dolog a restful api, de kliensen is azt használod? Foglalkozni kell a SEO-val? Mert akkor szerveroldalon is kell HTML-t generálni. Kliensoldalon generáljuk csak? Valami javascriptes gányolás lesz a vége, ami tetűlassú, és csak a legújabb böngészőkben működik. Mindkét oldalon kell generálni? Akkor kétszer kell megírni a renderelést.
25

Jogosak a felvetések és az

smokey · 2016. Aug. 4. (Cs), 21.03
Jogosak a felvetések és az észrevételek. A tisztán kliens oldali HTML generálásnak nyilván akkor van értelme, ha a szolgáltatásunkat nem szeretnénk SEO-zni - esetleg azért, mert jogosultsághoz kötött.

Egy termék fejlesztése esetében mi pl csináltuk már azt, hogy egy jó WordPress oldal a landingpage, amibe tudunk dinamikus tartalmat is generálni, pontosan a SEO miatt (plusz van hozzá egy blog is), és innen tudsz navigálni egy másik oldalra, ahol fut az authentikációt igénylő alkalmazás (innetől kezdve niincs értelme a SEO kompatibilitásnak).

Itt egy AngularJS alapú kliensről és egy Java-s backendről (ami most 5 szerveren fut) beszélünk. Nem mellesleg a backendet használja még két mobil alkalmazás és egy böngészős bővítmény.

És igen, egy hírportál esetében nem teljesen ilyen architektúrára van szükség.
28

Mobil

Hidvégi Gábor · 2016. Aug. 5. (P), 09.58
De ha van angular kliens, akkor miért van szükség mobil alkalmazásra?
30

Azért van szükség,

smokey · 2016. Aug. 5. (P), 11.32
Azért van szükség, mindegyikre, mert a natív mobilappok mobilra optimalizálak, az Angular kliens pedig böngészőre. Nincs értelme kitenni egy mobil appba azokat a feature-öket, amit böngészőn keresztül használsz, és fordítva.
32

Például?

Hidvégi Gábor · 2016. Aug. 5. (P), 11.47
Még nem dolgoztam mobil alkalmazással, ezért kérlek, tudnál példát írni a fentiekre? Tehát olyat, ami csak böngészőben van és olyat, ami csak mobilon? Mi az, amit csak itt és csak ott lehet/érdemes használni?
34

Tegyük fel, hogy van egy

smokey · 2016. Aug. 5. (P), 12.35
Tegyük fel, hogy van egy szolgáltatásod, aminek a végeredménye egy rakat kimutatás. A szolgáltatás része az is, hogy a kimutatásokat össze tudod építeni egy grafikus felületen, sőt, az is része, hogy mindenféle rendszerből tudsz adatot küldeni, amiből aztán a kimutatások generálódnak.

Mobilon kifejezetten jó a kis méretű, akár lapozható kimutatásokat nézegetni, plusz tudsz reagálni egy kimutatás eredményére. Pl.: kommentelhetsz értékeket: "Az ott miért annyi?", vagy "Az ott miért csökken olyan gyorsan?"

Viszont,

Mobilon nem kényelmes felépíteni egy riportot, mert sok komponensből tudsz összerakni egyet, és azokat jó látni egy képernyőn, mert akkor látod, hogy miből tudsz építeni.

Weben sokkal hatékonyabban lehet kapcsolódó adminisztrációs tevékenységeket végezni, mint pl táblázatokat nézegetni, entitásokat karbantartani, hosszas kiértékelést írni, vagy éppen összeépíteni azt az adott riportot, esetleg hírlevelet gyártani.

És, hogy visszakanyarodjak: a fent említett mindenféle rendszer (pl.: SAP, vagy bármi middleware) a webes kliens és a mobil kliens is ugyanahhoz a backendhez kapcsolódik, mert egy központi helyen tudod kezelni a jogosultságokat, egy közös helyen nyúlsz adatbázishoz, logolsz, mérsz, stb.

A fenti példa természetesen ki van sarkítva szándékosan az összes ponton, ahol próbáltam szemléltetni a kérdésedre a választ; és ez egy általam nem lefejlesztett csak vizionált példa :).
36

Mobilon kifejezetten jó a kis

Hidvégi Gábor · 2016. Aug. 5. (P), 13.53
Mobilon kifejezetten jó a kis méretű, akár lapozható kimutatásokat nézegetni, plusz tudsz reagálni egy kimutatás eredményére. Pl.: kommentelhetsz értékeket
Nem igazán látom, miért ne lehetne ezt weben egyszerűen és gyorsan megvalósítani. Tudsz jobb példát mondani?
37

Érzem én, hogy nem tudlak

smokey · 2016. Aug. 5. (P), 14.12
Érzem én, hogy nem tudlak meggyőzni :).

Ezért sarkítottam, vegyük a másik oldalát: Mennyire egyszerű egy 6-7 oszlopos 10-20 soros táblázat áttekintése, vagy akár egy értékelés megírása mobilon? Nem megoldhatatlan, sőt gyorsan megoldható, viszont, lesz az a felhasználó, aki azt fogja mondani, hogy "minden vágyam egy táblázat böngészése és egy kisregény megírása volt a mobilomon"?

Ha mobilon az ilyen és ehhez hasonló feature-öket nem használja, akkor miért fejlesszük bele? Másrészről, egy komoly termék esetén miért ne lennék elégedett egy natív appal, ami az oprendszerre optimalizált, szemben egy mobil böngészőben futó admin felülettel (ami mondjuk egy desktop böngészőben kiválóan használható)?
38

Bennem csak az motoszkál,

Hidvégi Gábor · 2016. Aug. 5. (P), 14.45
Bennem csak az motoszkál, hogy ha van egy kiválóan használható webes kliens, akkor minek fejleszteni egy mobilklienst is? Kétszer annyi meló.

Ha engem nem tudsz meggyőzni, akkor hogy adtátok el a főnökötöknek?

Másrészről, egy komoly termék esetén miért ne lennék elégedett egy natív appal, ami az oprendszerre optimalizált
Tehát lassú a webes alkalmazás. Pont erre utaltam a 24-es hozzászólásomban:
Kliensoldalon generáljuk csak? Valami javascriptes gányolás lesz a vége, ami tetűlassú, és csak a legújabb böngészőkben működik.


Az rendben van, hogy a szolgáltatás admin- és felhasználók számára publikus felülete külön van, de hogy az utóbbira két klienst is elkészíteni, nekem soknak tűnik.

Amit elképzelhetőnek tartok, hogy bizonyos eszközök miatt, amiket csak natív alkalmazással lehet elérni, kell/érdemes külön mobilklienst készíteni. Érdekelne, hogy mik ezek.
39

Túl off

Pepita · 2016. Aug. 5. (P), 17.37
Kedves Uraim,
Nem lehetne erre egy új topic ot nyitni?
Már kb 30-40 comment nem a feltett kérdésre válasz + mobilon már nem is látni portrait. A srác meg nem találja meg a neki relevant infót, mert bő 90% nyi off közül kell kiválogatnia.

Gábor, az utolsó kérdésedre Szívesen mondok példát másik helyen.
41

Egyetértek! Szívesen

smokey · 2016. Aug. 6. (Szo), 09.28
Egyetértek! Szívesen folytatnám ezt a szálat, és jogos, hogy itt nincs jó helyen!
29

És igen, egy hírportál

Hidvégi Gábor · 2016. Aug. 5. (P), 10.57
És igen, egy hírportál esetében nem teljesen ilyen architektúrára van szükség.
Szerintem pedig szinte minden weboldalnak és -alkalmazásnak erre van szüksége, csak ilyen Angularokkal meg Reactokkal soha nem fogod tudni normálisan megvalósítani, mert egyrészt a logika nagy része a kliensoldalon van, másrészt tetűlassúak.
31

Ha kliens oldalra rakod a

smokey · 2016. Aug. 5. (P), 11.35
Ha kliens oldalra rakod a logikát, akkor ott van... Erre való a backend, hogy megvalósítsa az üzleti logikát, és a backendre tudsz kapcsolni több klienst, amik az üzleti réteget konzisztens módon tudják használni.

Másrészt, miért terheljem ugyanazt a szervert üzleti folyamatokkal és HTML generálással ha szét tudom választani?
33

Kliens

Hidvégi Gábor · 2016. Aug. 5. (P), 11.50
Inkább mindig kiterheled a kliensre, bár elképzelésed sincs, milyen erőforrásokkal rendelkezik?
35

Ha ügyesen rakod össze az

smokey · 2016. Aug. 5. (P), 12.43
Ha ügyesen rakod össze az olyan féle klienseket, amiket felhoztam példának, akkor nem szabad, hogy sokkal nagyobb terhelést kapjon a böngésző, mint egy PHP által kigenerált HTML oldal.

Ami nagyobb erőforrást igényel, az egyedül a sablonok kezelése és a routing feloldása. A többi dolog (ajax kérések, jquery, javascript alapú validáció, stb) szinte az összes modern weboldalnak részét képezik.

Ha ezt valakinek a böngészője nem tudja feldolgozni, akkor ott vannak komolyabb problémák is szerintem.
11

fogalmak

Pepita · 2016. Aug. 3. (Sze), 17.43
Kicsit itt össze keveredett a webservice és a rest API illetve bármilyen API. Webservice egészen más.
Az pedig egy igen megerőszakolt elmélet, hogy ne használj session t.
17

Hát nem tudom... Én itt ezt

smokey · 2016. Aug. 4. (Cs), 08.29
Hát nem tudom... Én itt ezt egész másképp látom. Jó pár éve követjük ezt az elméletet és eddig csak nyertünk vele.
27

Az ott a REST

Pepita · 2016. Aug. 5. (P), 09.40
És belinkelve az oldalon
a webservice
és az RPC is. Ezek nem ugyanazok.

SZERK.: az itt lejött, hogy ti REST API-t nyomtok, de ez nagyon offtopic egy véleményt kérő node-on, és nem ez az egyetlen jó megoldás sem.
12

Húha

Pepita · 2016. Aug. 3. (Sze), 18.07
Most mobilon néztem, hát elég fura. :)

Belépés: inkább ezt a formot kéne állandóan kitenni, ha nincs belépve, reget a menübe. Fb stb login is login, nem reg.

Email: php. Ez valid lett volna, te dobtad el.

szín: rögtön f5 nyomtam, nem figyeltem... utána jó volt. Vmi cache lehet?

Url: nem csak így lehet, nyugodtan viheted tovább session v cookie is, de a választási lehetőséget mindenképp érdemes állandóan linkelni. Minek kell a régió? Használod valamire?

Session: az óvodás hacker is elsőre ezt a sütit keresi pl xss attack során. És nem szerencsés az md5 hash sem ma már.
azt is érdemes szem előtt tartani, hogy másik op rendszeren vagy böngészőn már ne működjön ugyanaz a session. Ha mégis vhogy el lopják vki sütijét, akkor ne legyen túl egyszerű felhasználni.
Egy valamirevaló felhasználó kezelés nem használ "gyári" php session t, hanem saját egyedit.

Szerk.: a session nem jó törölni, ha logout van, csomó értékes információ elvész, pl a nyelvi beállítás is. Csak azokat az adatokat töröld, amik user logged in miatt fontosak.
amúgy süti login van? Azzal nagyon vigyázni kell, ne tudja hacker ellopni, felhasználni.
14

Session: az óvodás hacker is

Hidvégi Gábor · 2016. Aug. 3. (Sze), 20.01
Session: az óvodás hacker is elsőre ezt a sütit keresi pl xss attack során. És nem szerencsés az md5 hash sem ma már.
Erre való a httpOnly sütemény, és akkor mindegy, hogy nevezed.
15

macska - egér

Pepita · 2016. Aug. 4. (Cs), 07.01
Egyszer legyen elég időnk fogócskázni egyet, szívesen játszanék veled süti lopósat... :)
Mondjuk én védekezni szoktam, de pandúrból lesz a legjobb rabló.

(Xss nem kizárólag JavaScript)
19

Xss nem kizárólag

Hidvégi Gábor · 2016. Aug. 4. (Cs), 08.58
Xss nem kizárólag JavaScript
Akkor még micsoda?

Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications. XSS enables attackers to inject client-side scripts into web pages viewed by other users.
A wikipédiáról.
26

<img src="valami_php_script.jpg />

Pepita · 2016. Aug. 5. (P), 09.37
<img src="valami_php_script.jpg />
Persze kiszolgáló beállítva, hogy jpg-n is fusson PHP interpreter.
Miután kilolvastam a sütiket, matekoltam vele, amit akartam, adok neked egy jpg képet is, hogy azt hidd, nem történt semmi.
XSS nem kizárólag client-side scripts. Fenti megoldással legalább ugyanannyira "átszkripteltem" egyik site-ról a másikra.

Szerk.: csak ezt az img taget kell elhelyeznem a célpont oldalon, pl. ha engedi a html commentet, már jó is...
40

Péter, ha nem vagy biztos egy

Joó Ádám · 2016. Aug. 5. (P), 19.05
Péter, ha nem vagy biztos egy állításodban, akkor előtte nézz utána. Ha biztos vagy benne, akkor legyél kevesebben biztos.

A sütik domainhez kötöttek.
42

ennél részletesebben?

Pepita · 2016. Aug. 6. (Szo), 13.53
Ádám, ezzel nem tudtam meg új infót:
A sütik domainhez kötöttek.

nem is mondtam olyat, hogy másik domain sütijét vizsgáljuk.

Egy nagyon egyszerű és régi dolgot írtam le, ezek szerint számodra nem elég érthetően. Nem szeretném jobban részletezni, mert nem kedvcsináló akartam lenni ebben a témában.
43

nem is mondtam olyat, hogy

Joó Ádám · 2016. Aug. 6. (Szo), 14.35
nem is mondtam olyat, hogy másik domain sütijét vizsgáljuk


Tényleg nem, de ez az egyetlen olyan kontextusa az általad írtaknak, amiben azok egy támadásként értelmezhetők. Ha a szkript a céldomainen fut, akkor mi értelme képnek álcázni?
44

Attól tartok,

Pepita · 2016. Aug. 6. (Szo), 15.30
itt nagyon elbeszélünk egymás mellett.
Bő 5-6 éve olvastam erről egy cikket, azóta az az egy biztos, hogy "nagyon nem szeretem" az idegen url ről származó képeket.
Sajnos ezt a cikket telón nem találom. :(


Szerk. Szerintem mi is igen off ba mentünk.
45

Most mégis „idegen URL”-t

Joó Ádám · 2016. Aug. 6. (Szo), 17.45
Most mégis „idegen URL”-t írsz. Ezért szóltam, hogy mielőtt tanácsot adsz, főleg ha biztonság kérdésében, ellenőrizd a mondandód, mert ezeknek az eredménye nagyon sok tévhit.
46

Köszi a választ, sokat

vmarci21 · 2016. Aug. 7. (V), 16.23
Köszi a választ, sokat segítettél. ;)
Javítom a hibákat.