Čačkam nešto, mučim se, učim, pokušavam za naše vlastite poslovne potrebe složiti neku jednostavnu web aplikaciju. Dostupni resursi (prvenstveno reference manuali pa onda forumski threadovi i blogovi po internetu) su vrlo korisni i služim se njima obilno, ali svejedno imam neka pitanja, što načelne, što praktične naravi. Početnička, naravno, pa molim znalce da mi se ne smiju jako, ako pitam nešto trivijalno.

A. PHP / MYSQL pitanja

1. Kužim logiku i svrhu $_SESSION podatkovne strukture. Prilikom logina kreiram nekih 6-7 $_SESSION varijabli. Sve rade uredno od prve, osim $_SESSION['baza_poslovanja'] za koju kod pokušaja dohvaćanja dobivam NULL. Kad sam to promijenio u $_SESSION['bazaposl'], sve radi. Pretpostavljam da problem stvara underscore (znak "_") ili pak duljina imena (15 znakova). Nisam uspio naći da negdje decidirano piše koja su ograničenja u ovom smislu, a volio bih točno znati, da u budućnosti ne gubim vrijeme s tim.

2. za mysqli_connect treba MySQL serveru proslijediti korisničko ime i password korisnika koji ima odgovarajuća prava pristupa na konkretnoj bazi na koju se želim spojiti. To je sve jasno.
Moje pitanje je, ako proslijeđujem korisničko ime i password MySQL korisnika kao $_SESSION['korime'] i $_SESSION['zaporka'], u kojoj je to mjeri sigurno rješenje?
Ovako od oka meni se čini sigurnije od toga da mi u PHP skripti direktno u cleartextu piše korisničko ime i lozinka (na stranu to što bi mi to stvorilo problem jer će biti nekoliko korisnika, od kojih samo jedan ima ovlast nešto brisati i neke određene stvari mijenjati), ali možda griješim jer stvarni sadržaj PHP skripte ionako nije dostupan kroz HTTPS?
Kako se to inače radi?

3. malo me iznenadilo da u svakoj novoj php skripti treba iznova na početku raditi mysqli_connect jer se konekcija gasi sa završetkom prethodne PHP skripte. To mi djeluje nekako... neefikasno.
Čitam nešto (površno) po netu da konekcija na bazu može biti "persistent" (ne znam kako bih takvu konekciju kreirao), ali da to opet nije ono što bi čovjek očekivao (da jednom prijavljeni korisnik na tom hostu ima otvorenu sesiju na bazi, sve do odjave), nego nešto ne znam što (hrpa informatičarskog teksta napunjenog terminologijom koja mi nije bliska ).
Pa onda ne znam ima li to uopće smisla prtljati s tim persistent konekcijama ako uzmemo u obzir da se radi o bazi od nekoliko tablica i sveukupno debelo ispod 1000 zapisa te ukupno 4 korisnika?

4. ad 3, da li se konekcija na bazu SIGURNO raskida automatski kod završetka PHP skripte? Da ne dođe nakon određenog vremena korištenja do nekog raspada zbog prevelikog broja otvorenih "umrlih" konekcija?

5. ima li bolji (efikasniji) način za izbrojati ukupni broj zapisa u tablici od ovog?


Ima li u takvom načinu dohvaćanja ukupnog broja zapisa neka kvaka koje nisam svjestan?

6. pretpostavljam da debugger u Firefoxu koristi jedino za Javascript, jer se PHP izvodi na strani servera, ali pitam za svaki slučaj, ako postoji neki, ne znam, "signalling" port za potrebe razvoja, štojaznam... Naime, takav sustav uredno postoji na automatičarskim sustavima u čijem sam programiranju više iskusan pa mi je palo na pamet...

7. u slučaju da je odgovor ad 6 negativan, kako se inače rješava problem debugiranja PHP skripte? Kužim da uvijek mogu napraviti echo $nešto i ispisati u HTML neku pomoćnu vrijednost da vidim što se događa, ali ovisno o tome odakle se skripta poziva (npr iz javascripta koji očekuje samo izlazni JSON), to se neće uvijek ispisati pa sad prtljam nešto preko $_SESSION varijabli, ali siguran sam da to nije "the way".

Imao sam još dva javascript pitanja ali sam putem, dok sam tipkao ovih prethodnih 7, sam sebi dao odgovor na njih pa za sada samo ovo...

Hvalaaaaa!!!

Ne usudjujem se pametovati oko ostalih tocaka jer sam uvijek koristio rjesenja sa gotovim funkcijama za spajanje na bazu i upravljanje sessionima, jedino za tocku 6. mislim da ti nema druge nego raditi debug na serveru, lokalnom ili remote.

Server je virtualni, na virtualnom edgeu, na mainframeu u data centru (dakle dupla virtualizacija, ali to i nije bitno). Gore je CentOS 7, kernel 3.10.0-1160.11.1.el7.x86_64, a ja pristup imam kroz cpanel 92.0. Servisi su apache 2.4.46, PHP 7.2.34, MySQL 5.7.32.
Mogu pristupiti i terminalom (ssh).
Kako se debugira PHP na serveru?

Samo da napomenem da se nisam ozbiljno bavio s ovim jos od PHP verzije 6, tako da sam vjerojatno u krivu s dosta toga, ali evo mojih 50c.

1.) Ovo stvarno ne znam, jer nisam nikad pretjerano koristio $_SESSION, ali prije bi rekao duljina imena nego underscore. Session je meni prekratko, ja bi to uvik spremio u cookie (naravno ne usename i pass u cookie, nego neku svoju skrivenu vrijednost tipa 'login successful' i timestamp)

2.) Pa koja je razlika? Mislim, ako ces koristiti $_SESSION varijable opet njima moras negdje zadati tu vrijednost, zar nece i to proci kroz clear text
Ja sam osobno uvijek koristio clear text, ko sto si sam reka ionako stvarni sadrzaj PHP skripte nije nigdje dostupan, to se izvrsi na samom severu.
Ako ti se netko dokopa pristupa backendu da moze procitati PHP skriptu, to je vec problem s druge strane

Btw. ako sam dobro skuzio, svaki user koji se logira u taj web app ce imati i svog usera na SQL serveru?
Opet to je malo drugaciji pristup nego sam ja ikad radio. Ja bi uvijek napravio jednog SQL usera za samu web app (sa dovoljno permissions ali ni slucajno root) i svaka konekcija na SQL ide pod njim (nesto kao machine account). Authentication i permissions usera koji se logiraju na taj web app bi uvijek bila na PHP strani.

3.) u pocetku je i mene to cudilo, ali naviknes se, mislim da je to neka limitacija u samoj strukturi PHP-a

4.) ja sam uvijek na kraju svake skripte rucno zatvara konekciju, mysqli_close(), just to be safe

5.) pa mozes jos i koristiti mysqli_affected_rows(), naravno onda ce SQL query biti 'SELECT * FROM projekti' ako si zelio izbjeci fetch ali mislim da nema neke pretjerane razlike

6.) koliko je meni poznato, ne

7.) mozes u php.ini ukljuciti display_errors

songoku kaže:


Hvala ti na odvojenom vremenu!



Da, to mi ne igra jer username i pass moram proslijediti SQL-u.



Pa - ne, ovako se pass ne pojavljuje nigdje u cleartextu jer ga korisnik unosi u password polje prilikom logina.

Ali - nisam siguran je li $_SESSION struktura dostupna samo PHP-u, dakle na serveru, ili joj se može pristupiti kako drugačije (ne računajući da netko ima ssh pristup serveru)?



Ma da, vidim da većina (što sam proučavao po webu) radi kao i ti. Ne znam, meni se ne sviđa to tako. Korisnici imaju različite ovlasti. Ako to napravim tako kako opisuješ ti, onda svu kontrolu pristupa i ovlasti moram kodirati u PHPu. Ako nešto tu zaje*em pa se desi da mi netko nešto nehotice obriše, jbg. Ovako - poklikam ovlasti u SQLu i ne boli me glava.



Aha, e, ok, tako ću i ja, hvala. Fata je Fata, al' dvaput je dvaput.



Me no like. Tramaka se puno veća količina podataka kroz skriptu, a bez potrebe. Više sam mislio ako postoji funkcija koja direktno iz korijena baze pročita već zapisani broj zapisa u tablici bez potrebe da se pokreće query. MySQL izraz SELECT COUNT(*) FROM tablica parsa jako jako brzo jer samo pogleda u korijenu baze zapisani podatak o broju zapisa.



Aha, ček ček! Gdje nađem php.ini? U home folderu? Ili u nekom... kojem? Ima li ga negdje kroz cpanel?

I onda ako je uključeno display_errors, gdje se onda to vidi?

smayoo kaže:


Triba bi biti u cPanelu, ali mozes jednostavno provjeriti di je sa phpinfo()

Kad ukljucis display_errors to ce u samom outputu skripte u generiranom HTML-u ispisati i error tamo di se desio.

To mi nije baš korisno
Naime, PHP skriptu poziva javascript biblioteka koja od PHP-a samo uzme zadnji output - print json-a dataseta - a bilo koji echo, print ili bilo što drugo se ne prikazuje nigdje jer javascript to tako zapakira.

Nisam siguran, ali mislim da bi isto triba ispisati errore u JSON koji outputa, sorry nisam bas puno radio sa JSON-om.

Mislio sam da je rijec on nekom jednostavnom projektu, meni je uvijek bilo lakse samo ukljuciti display_errors pa reproduce i gledati u output.
U tvom slucaju mozda bi bilo bolje ukljuciti logging u file.

log_errors = on
error_log = /path/to/your/error.log

Pretpostavljam da hoces verbose, onda error_reporting = E_ALL

Hvala, probat ću to.

Projektić je jednostavan. Relacijska baza od tri tablice. Tablica projekata 1-na-n vezana na tablicu zabilješki. O svakom projektu ima više zabilješki koje unose razni ljudi, ovisno tko što kada radi. Treća tablica je samo lookup, za sad, u kojoj su popisani svi poslovni subjekti involvirani u projektima. Iz tablice projekata se na ovu tablicu referira iz više polja (investitor, naručitelj, izvoditelj...).

Front end slažem pomoću jTable (svojedobno mi ga je Đipi predložio, hvala, Đipi!) jer je upravo to ono što mi treba - tablični prikaz projekata, s one-click otvaranjem podtablice inline.

Ovo pitanje oko debugiranja je najviše zato što PHP skripte koje pišem, a koje se pokreću kroz jTable funkcije, nemaju vidljivi <div> u kojem bi se pojavio bilo koji sadržaj (ispis greške, echo bilo čega, išta...). Stvar je složena tako da na kraju skripte napraviš

print json_encode($rezultat)

i onda javascript pokupi json formatiran tekst s podatkovnom strukturom koju treba prikazati.

Čak i da u taj json upadne neki debug string, ja ga opet ne bi vidio jer jTable primljeni json jednostavno odbaci, ako nije složen kako ga očekuje, i kaže "greška u primljenim podacima".

1. $_SESSION nema takvih limita, niti sam se ikad susreo s takvim problemima. Ne mogu tocno reci u cemu je problem, ali meni $_SESSION['baza_poslovanja'] radi bez problema.

2. Moguc je session hijacking i takve stvari se ne bi trebale tamo drzati. Koliko razumijem, radi se o podacima za pristupu bazi. U tom slucaju je praksa imati odvojeni config file (PHP, YML, XML.. nije vazno) u kojem se nalaze podaci za pristup. Mora se samo pripaziti da dokument nije dostupan izvana i da ima odgovarajuce file permissione.

Koliko vidim username i password korisnika se koriste za pristup bazi sto je big NO (bad practice, tesko rjesavanje password reseta, dodavanje i uklanjanje korisnika, autorizacije, sigurnosni rizik, itd.). User authentication to se rjesava na nacin da se u bazi drzi username i password za svakog korisnika, kao i privilegije usera (to je vec sfera authorizationa) i to bi sve trebalo odraditi u PHP-u. To se obicno rjesavanja kreiranjem rola koje imaju predifinirane privilegije. Spajanje na bazu bi trebalo imati jednog MYSQL usera (koji nema veze s korisnicima sustava).

Za bolje razumijevanje, session i cookie su jedna te ista stvar, samo se jedan sprema na serveru, a drugi na klijentu.

3. Normalno je raditi novu konekciju.

4. Trebalo bi zatvoriti konekciju i ne oslanjati se na garbage collector. Ovdje nece biti problem, ali inace prevelik broj otvorenih konekcija moze usporiti sustav.

5. To je efikasni nacin.

6. Za debugging se koristi Xdebug. Treba biti instaliran na serveru i podesen u IDE-u. Kako je sad ne znam, ali su prije IDE-i imali komplicirani config dok se sve upogoni. Koristim PhpStorm koji ima built-in podrsku pa je setup jednostavan, a navodno je jednostavan i kod VSC-a, ali nisam nikad probao.

7. Odgovor je u 6. Inace konfiguriranje u php-ini-ju sto pisu je za output PHP gresaka (ako do greske dodje). Nije za debugging u smislu koji trazis.

yawn pong, hvala na detaljnim odgovorima i pomoći! Ovo je jedino što me muči:


Nadam se da te neće uvrijediti, ali "big NO" i "bad practice" mi ne govori dovoljno. Koncept da imam "one user for all" i da taj password piše u svakoj PHP skripti, a onda u takvoj bazi pišu passwordi i dozvole pristupa za sve korisnike, meni je to šupalj security. Baš do kraja.

Razlozi koje navodiš: teško rješavanje password reseta, dodavanje i uklanjanje korisnika - to razumijem - praktični problemi kad radiš aplikaciju za naručitelja koji nema osobu koja zna to odraditi kroz PHPmyadmin i/ili ima jako puno korisnika i sl. - ali meni to nije bitno, radi se o nas četvoro.

Razlog "autorizacija" - nisam shvatio što točno misliš pod tim? Ista 4 korisnika s djelomično istim usernameom i istim passwordima imam upisane u drugoj bazi (ne istoj) i to koristim za login. Dakle, kod svake manipulacije s passwordom to treba upisati na dva mjesta, a korisnici si ne mogu sami izmijeniti pass. Jesi li na to mislio?

Razlog "sigurnosni rizik" nije razlog. I ova druga praksa je sigurnosni rizik.

Ali prihvaćam da nije sigurno čuvati username i pass u $_SESSION. Riješit ću to na drugi način.

7.
Za isprintati nešto korisno je file_put_contents.
npr.

Ako imaš command line pristup serveru odlično, gledaš tamo što se zapiše u fajl.
Ako nemaš, otvori u web browseru taj fajl.
(pripazi samo da ti fajl ima ispravne permisije da se može pisati u njega)

A! E, to je to! Hvala!

Bio to supalj security ili ne, danas se to tako radi. Naravno da lozinke moraju biti hashane. Ako se ti osjecas sigurnije u MySQL-u nego u PHP-i to je u redu i radi onda tako, ali ti govorim kako se danas rade aplikacije.

Autorizacija je odredjivanje ima li korisnik privilegiju za odredjenu radnju.

A kako se pošalje hashanu lozinku mysql serveru iz PHP-a?

Ja se na bazu spajam ovako:


ovo $_SESSION['lozinka'] sadrži lozinku MySQL korisnika u cleartextu. I u svim primjerima koje sam po netu našao, svi uvijek kroz mysqli_connect šalju cleartext lozinku. Hash lozinke spremljen je u samoj bazi, server primi cleartext lozinku i koristi je kao challenge na zapisani hash. Rezultat mora biti eigenvalue (da se izrazim matematički, dakle 0, ili 0xffffffff, ili koja već je s obzirom na hash algoritam) i to je onda potvrda da je lozinka ispravna.

Logično, jer se lozinka *NIKAD* ne pohranjuje nigdje u cleartextu. U bazi je pohranjen hash, korisnik utipka cleartext, challenge, response, to je to.

Ako ja sad na još nekom mjestu (u nekom fileu, u drugoj bazi, ovdje, ondje) pohranjujem lozinku da bi je prilikom spajanja poslao serveru, kako da je pohranim hash-anu? Od hasha se ne može rekreirati izvorna lozinka. Ako mysql serveru pošaljem hash lozinke, on ga ne može dati kao challenge svom hashu. To su dva različita hasha istog izvornika (cleartext lozinke), ali nema matematike koja ih može jednoznačno spariti bez originala.

Ili nešto ne znam? Je li se tu nešto promijenilo od vremena kad sam se time intenzivnije bavio (prije 25-30 godina)? Mislim - jest - povećao se broj bitova enkripcije i tako to, procesori su brži, ali - zar se koristi neki drastično drugačiji algoritam??

Ne radim vanilla php, ali radim u okviru wordpressa.

Riba kaže:


Za wp postoji ovo wordpress.org/plugins/query-monitor/ ... ukratko kao chrome dev tools za php stranu wordpressa nudi uvid u queryije hookove ... i jos dosta toga.

Pa zguglah ovo: www.ma-no.org/en/programming/php/easy-de...php-and-chromelogger i ovo www.cloudways.com/blog/php-debug/ ... mislim da mora postojati neko riješenje gdje kombinacija neke chome extenzije i podešenja na webserveru (php.ini i sl) ... moze proces uciniti vise user - friendly.

Ali mislim da je puno bolje riješenje mora biti putem Composer.
Opet googlanjem nailazim na ovo: phpdebugbar.com/

Dodatno moja preporuka bi bila phpcs, postoje exentzija za editore, recimo ja koristim vscode pa je extenzija marketplace.visualstudio.com/items?itemName=ikappas.phpcs

Nije za debugging ali ... jako dobar linter.

@smayoo ... si razmišljao o learavel php frejmworku?

Nisam. Imam jedno jako loše iskustvo sa svim tim nadgradnjama (wordpress i tako to). Jednom u bivšoj firmi nam je jedan "stručnjak" ponudio izradu weba jeftinije nego što ga je prije toga (vrlo funkcionalno i dopadljivo) napravio Kreativni odjel. "Stručnjak" je nešto s prstom u nosu naklikao u WPu (i čemu još ne) i tri mjeseca kasnije nas je hosting service šutnuo sa servera jer je "stručnjak" nainstalirao hrpu nečeg što je imalo hrpu poznatih sigurnosnih rupa pa je naš server postao hub za distribuciju spama ili nešto još gore.

Kako god bilo, nemam ni vremena, a ni potrebe da vodim brigu o svim tim s*anjima i svakodnevno proučavam hrpu nekih newslettera ne bih li bio u toku koji se gdje . To što mi treba je vrlo jednostavno. SQLa znam i više nego dovoljno, PHP je trivijalan jezik i jedino što mi stvara probleme je ta javascript ljuska za tabličnu vizualizaciju koja je manjkavo dokumentirana, ali dobro, već sam se uhodao...

Mislim da se nismo razumijeli ... nisam predlagao da koristis wordpress (iako problem koji ste imali nema veze s wordpressom nego s covjekom koji je radio posao), mislim i jabucnjak je na joomli pa nije postao distribter spama.

Linkovi koje sam dao su samo trebali sugerirati da alat za debuging slican js debuggeru (dakle da ga se koristi u browseru ili editoru a ne u logovima servera) je moguce podesiti. Wp primjer je samo kao proof of concept, a ostali linkovi mi se čini da upučuju na moguce native php rijesenje.

Laravel s druge strane nije baš slican wordpressu. To je framwork a ne CMS i ne funkcionira po princiupu (mislim ako je riječ o "stručnjaku" ni wordpress tako ne funkcionira) sto god mi treba samo puknem plugin. Ali ubrzava rad jer za često potrebne stvari postoje već patterni kako ih kvalitetno napraviti ... pa je to u laravelu zapakirano u neku funkciju(), objekt::, {template} ...

Laravel je neki solidan smjer u kojem php development u zadne vrijeme ide ... pa rekoh ... why not.

A composer je nodejs eqvivalent za php ... tooling, nothing more.

Vjerujem ja tebi da nije problem u tako nečem, nego u "stručnjaku", ali u tom sam filmu i ja takav "stručnjak". Poanta je u tome da nemam vremena, niti volje, niti znanja, paziti i proučavati što će me od svega toga izložiti nekom napadu.

Za savjete hvala, pogledat ću. Načelno, ništa što zahtijeva Chrome mi ne dolazi u obzir. A PHP mi je stvarno toliko jednostavan da ne vidim veliku korist u daljnje pojednostavljivanje. Praktički su sve te skripte samo tramakačice podataka između mysqla i htmla ili jsona.

ecvis17 kaže:


:-X

U pravu si. Za spajanje na bazu moras imati clear text lozinku. Ovo je kod jednog usera za spajanje na bazu, a customer lozinke se spremaju u bazu.

@smayoo
ma kužim tvoju perspektivu, ne misliš krenuti raditi redovito web appove pa ti nema smisla ulagati vrijeme u savladavanje frejmworka i sl.

Ne samo to, nego ne želim da najedamput moram voditi brigu oko administriranja servera 10x više nego do sad samo zato što sam nainstalirao hrpu nekih 3rd pary "black boxova" za koje u osnovi nemam pojma što i kako rade, niti koliko često moram voditi brigu o njihovom updateanju, i sl. Sve mi je to "the windows way".

yawn pong kaže:


Elem, vraćamo se na to da je (makar se i 100x to tako radilo) takav pristup loš i nesiguran.

S druge strane, spomenuo si da je moguć session hijacking pa je iz tog razloga nesigurno čuvati cleartext password koju je korisnik unio prilikom logona. Koliko sam popratio, session hijacking napad mora biti ciljan i planiran. Dakle, netko se mora baš na naš server "napičiti" i čekati spreman kad neki korisnik inicira sesiju. Kad se to dogodi, ili će natjerati server u connection drop DDOS napadom, ili će se injektirati u HTTPS vezu "man in the middle" metodom (što može isključivo u trenutku uspostavljanja te veze, i to pod pretpostavkom da ću ja ignorirati upozorenje FireFoxa o tome kako nije validiran identitet servera). Ni jedno, ni drugo nije baš trivijalno izvesti i takvo što će ići raditi netko kome su strašno važni i potrebni moji podaci, ili misli da mi ih može zaključati i tražiti lovu (kao što su nedavno naguzili INA-u, a još prije nje HT). S obzirom na veličinu i globalni značaj moje firme od 4 zaposlenika, mislim da se još neko vrijeme ne moram toga bojati.

S druge strane, držati zapisan(e) cleartext password(e) za pristup mysql serveru i bazi u nekoj datoteci na disku servera je puno veći sigurnosni propust, jer su podaci stalno tamo, stalno dostupni, i štiti ih samo statički password ssh ili cpanel korisnika, do kojeg se može doći na puno veći broj načina i ne mora nužno uopće biti usmjeren ciljano na mene, nego prije na hosting service.

Tako da (rado bih čuo protuargumente, ali u međuvremenu) zaključujem kako "to se tako radi" je, kao i često puta u životu, loše rješenje koje se tako radi zato što je jeftinije/jednostavnije/netko nije spreman platiti za bolje rješenje.

smayoo kaže:


I jedno i drugo je valjan nacin, sve ovisi o tome sto radis. Za tvoj scenarij access kontrola na razini baze je prakticnija i sigurnija. Za aplikacije koji moraju hendlati tisuce korisnika i imati fleksibilni access kontrol unutar aplikacije recimo nije. Svaki alat ima svoju svrhu, kao i uvijek...

TL;DR: yawn pong ti je u svom prvom postu odgovorio (na temu čuvanja passworda) ono što bih ti i ja rekao (autorizacija i privilegije kroz app, a ne kroz bazu), a vidim da u nastavku threada "drviš" po svom pa bih u najkraćoj verziji zaključio sa "Napravi kako god ti radi, a da si zadovoljan".

Naime, nije jasno što točno radiš (zvuči kao neki elementarni CRUD) i za koga optimiziraš to što radiš. "Danas" (čitaj: zadnjih 10 godina) se optimizira "za korisnika" (jer su nas dobro napravljeni UI/UX-ovi, s pravom, razmazili), a koristeći rudimentalne alate s kojima pokušavaš riješiti problem (sirovi PHP + HTML + JS) to sigurno nećeš postići. Dakle, trebalo bi se vratiti na početak pa zaključiti možeš li elementarni CRUD napraviti jednostavnije (možeš - guglaj "CRUD generators"). Ako ti se to ne sviđa (jer se plaća i jer ovisiš o tuđem kodu), imaj na umu da je sve što moraš napraviti netko već napravio u nekom frameworku (od CodeIgnitera, za osnovni MVC pristup, nadalje, ovisno čija logika ti više paše i koji moduli ti zapravo trebaju - i kad kažem "moduli" imaj na umu da je i sam PHP, vanilla instalirana na serveru, također samo skup "modula"). Framework traži da poštuješ način koji je predvidio za razvoj appa (što znači da ga moraš naučiti), a zauzvrat ti krati posao i brine se o bezbroj problema u koje tek moraš udariti. Imaj na umu i da su PHP frameworci već "old school" jer se zadnjih valjda 10 godina za sve što je bazirano na korištenju front-enda (dakle web app) koriste JavaScript (!) frameworci tipa React/Angular. Zašto smo prešli iz PHP-a u ("kompajlirani") JavaScript? Zato jer je nekom došlo do mozga da JS može raditi isto što i PHP, a prednost mu je što može optimalnije komunicirati s front-endom. Nekome je prednost što ne mora učiti 2 jezika (PHP+JS) nego samo jedan (JS, odnosno jedan njegov "dijalekt").

Ako ostaneš pri svom rješenju (sirovi PHP + HTML + JS) imaj na umu da je razvoj na produkcijskom serveru također veliki no-no jer nehendlane greške kompromitiraju security. Zato se (a i zbog vlastite komocije) produkcijska okolina replicira na lokalnom stroju (uglavnom koristeći MAMP), radi se preko gita (i GitLab i GitHub nude privatne repozitorije za nula novaca, a ako si paranoičan ne trebaju ti ni oni) i deploya se u konačnici na produkciju.

Načelni odgovor na tvoje pitanje pod brojem (1) je opisan na www.php.net/manual/en/function.session-id.php, ali u praksi (primjerice, da li je dopušten underscore ili ne) ovisi o konkretnom PHP-u koji je (kompajliran i) deployan na tvom serveru. Vrijedi ono što je definirano u session.c fajlu. Pod (2) vrijedi ono od yawn ponga i polazi od pretpostavke da se credentiali za pristup bazi čuvaju na samo jednom mjestu (u nekom config fajlu, gdje su obično i druge konstante) i da fajlu u kojem se čuvaju nitko ne može prići - ako ne možeš zadovoljiti taj uvjet, kompromitiran si u startu. Persistentna konekcija (3) se svodi na to da prefixaš običnu sa "p:" (opisano je u manualu na php.net) i ne preporuča se (jer hoga). S druge strane skripta (po definiciji) nakon izvršavanja gasi otvorene konekcije pa, koliko god da je dobra praksa zatvarati ih u kôdu (podržavam!), zatvorile bi se i same (4). Za prethodno otvorenu konekciju, optimalan upit (u OOP formatu!) je:


(6) Debugger je (kao što je yawn pong već rekao) Xdebug, ali definitivno ima više smisla u kombinaciji s IDE-om (da pogodim, tipkaš PHP u... vi-u? ) pa se u praksi svodi na marketplace.visualstudio.com/items?itemN...ixfbecker.php-debug. Napominjem da je instalacija Xdebuga na produkcijskom serveru security risk.

Nevezano uz prethodno: uzmi u obzir da web appovi danas "bježe" od SQL baza u korist NoSQL baza jer NoSQL (MongoDB) bolje slijedi logiku dokumenata (koje koristimo u front-endu) i optimalnije rješava probleme ORM-a (Object Relational Mapper). Ako imaš fiksne tablice u bazi i ne previše stupaca u njima, možeš hendlati ORM i pješke ili kroz neki framework koji podržava ORM. Ali ako ti se struktura podataka mijenja, NoSQL može biti bolje rješenje. Ovo spominjem samo kao ilustraciju da "ni baze više nisu što su nekad bile".

Bottom line - čini se da je vrijeme PHP web appova prošlo. Ne kažem da će PHP izumrijeti (daleko od toga), ali to je danas posao za React/Angular, a ne za PHP kramp i lopatu. Ako je posao za PHP, onda je posao za neki framework. A ako ipak inzistiraš na tome da radiš kako si ti zamislio da je najbolje i zato jer ti se baš tako čini "najjednostavnije" - vjerojatno si činiš medvjeđu uslugu. Ali to i tako nećeš pojmiti dok ne probaš nešto slično napraviti na "aktualan način" pa si na miru.

Djipi kaže:


Da sam bio zadovoljan s rudimentarnim CRUDom, to bi sve već bilo gotovo i funkcionalno, i ne bi me uopće mučio problem debugiranja PHP-a, jer bi sve bilo napravljeno stvarno čistim krampom i lopatom (PHP i HTML, bez JS ).

Međutim, treba mi (želim) "tablicu u tablici", tj. relacijski prikaz. Tablica projekata i onda na klik, ispod jednog konkretnog projekta, tablicu bilježaka uz taj projekt.



Razumijem, shvaćam i - ne prihvaćam. Svakako si u pravu (i ti, i Riba, i yawn pong, i ostali) - ne bavim se ovim profesionalno, ne radim rješenje za ikog trećeg, ne kanim to nikom naplatiti. Ali najbitnije je da - moram to sam održavati. U 35 godina koliko ima da sa više ili manje intenzivno bavim programiranjem, kad god sam iskoristio nešto što je napravio netko drugi, ne bih li uštedio vrijeme, to je završilo tako da sam više vremena izgubio na debugiranje tuđih sranja, nego što sam uštedio time što nisam sam isprogramirao "from scratch".

Da se razumijemo, nije da ne bih radije i platio nekom da mi to napravi. Čak sam i pokušavao. Znaš kako je to završilo.

Uglavnom mi kažu - ne isplati se to raditi, nađi gotovo rješenje, odaberi neki SAS, plati pretplatu. Tu već imam problem što ne volim da netko drugi mrlja s mojim podacima čuva ih ili ne čuva kako treba, trguje njima i što ja znam. Ali veći je problem u tome što nijedan SAS nije usmjeren nekom tko radi moj posao (to je relativno uska niša, i još na malom tržištu) i ne odgovara mojim potrebama.

I tako, evo me tu gdje jesam.



Hvala ti na podsjetniku, znam to i to je rizik kojeg sam svjesno prihvatio. Zašto? Zato što nikad nisam uspio natjerati jbn MAMP da radi. Najgluplja i najtrivijalnija "step 1" stvar ne radi. Mysql server se ne odaziva. MAMP web server se kolje s apacheom od macos. I sve tako neka sranja. Jednostavno nemam dovoljno vremena da trošim na svu tu neku "baznu podlogu".

Da se vratimo na metaforu krampa i lopate, trebam rupu od 30x30x30 cm. Umjesto da idem na tečaj upravljanja bagerom i potpisujem ugovor o najmu bagera, lakše mi je i brže uzeti kramp i lopatu i ....



Ajde molim samo malo pomoći u razumijevanju ovog. Ako se ti credentiali čuvaju u nekoj datoteci, koji je to točno korisnik kojem pomoću chmod i chown trebam omogućiti pristup toj datoteci da bi je php mogao otvoriti i pročitati?



Ovo isto mi je već nekoliko puta nekoliko raznih ljudi objašnjavalo istim ovakvim riječima, ali problem je uvijek isti. Ja ne kužim o čemu pričaš. U prijašnjim iteracijama ovakvih situacija, ja bi obično upitao: 'OK, što to znači konkretno za mene? Kad želim iz baze dohvatiti na primjer sve projekte koje sam radio za tog investitora, a započeti su nakon tog datuma i imaju status "zaključeni" te za takve projekte izvući sve zabilješke koje sadrže riječi "sastanak" i "proširenje", ja točno znam kakav SQL query trebam natipkati i kako će ispasti rezultat kojeg ću dobiti. Zašto je noSQL baza bolja za to i kako da ja takav isti output dobijem od nje?' I onda bi (tako je do sad bilo) dobio odgovor 'pa da, pa ne, pa treba sad konkretno vidjeti, pa nije to ista organizacija, pa ovo, pa ono' ali ništa konkretno... Tako da je moj zaključak uvijek bio da je to fancy priča, ali ništa konkretno.



Od svega što sam u programiranju radio, najbolje sam zaradio krpajući stare (tuđe) COBOL aplikacije, kao student, ranih 90-ih. Tada se nije činilo da je vrijeme COBOL aplikacija prošlo, nego je bilo jebeno očito da je prošlo. Zato i jesam dobro na tome zaradio jer su nekom još trebale, a njihovi autori su počeli umirati i/ili odlaziti u penziju.

Ne kažem da ću se na isti način opariti na PHP-u , ali eto... opet mi je jeftiniji kramp i lopata od buldožera, a imam spomenutu rupu od 30x30x30 za iskopati...





Hvala ti na iscrpnom odgovoru! Iako neću poslušati tvoje savjete, to nikako ne znači da nisam nešto naučio.

Pa to je i dalje elementarni CRUD, sa specifičnim zahtjevom za front-end. Ako guglam "crud generator nested tables" dobit ću ovo kao prvi rezultat: www.phpcrudgenerator.com/tutorials/use-n...ap-admin-data-tables

No, preskočimo generatore iz razloga koje si niže naveo.



Ne znam što ti reći na ovo osim "meni radi" (a vjerujem i drugima). "Server se ne odaziva" može biti problem u načinu na koji se spajaš na njega (out-of-the-box ideja je da se spojiš na "localhost" i pritom koristiš "root" kao user/pass credentiale). "Kolje s apacheom od macos" može biti krivi port (možeš ih mijenjati u MAMP-u) ili ideš na krivi URL ("pravi" je localhost:8888 pa onda dalje u document folder). Ili je nešto deseto, ali vjerujem da je dokumentirano u manualu.



Eh. Ako nemaš vremena za baznu podlogu - o čemu pričamo? Da, možeš izgraditi app kopipejstajući snippete kôda s weba i možda čak bude radio. Ali takav pristup ne ide u paketu sa (opravdanom) paranojom u vezi sigurnosti podataka jer ćeš, ne znajući točno što radiš, sigurno pustiti iza sebe više od jedne "rupe".

Na tečaju za upravljanje bagerom bi te možda naučili da baš tu gdje si naumio ne smiješ samoinicijativno kopati jer je, eto, "kolega" koji je slijedio istu lako-ćemo logiku možda ukopao optički kabel na 10 cm dubine - pa ćeš ga probušiti. Then again - a možda i nećeš pa samo naprijed.



Onaj koji pokreće PHP procese na konkretnom serveru. Pogledaj u terminalu čiji su procesi ili ispiši iz PHP skripte (iako je potonje security no-no):




Da li je "bolja", "jednako dobra" ili "lošija" ne znam jer nemam uvid u konkretnu bazu i nije mi jasan problem koji rješavaš (s naglaskom na kriterij optimizacije), ali nije ni bitno. NoSQL query nije puno različitiji od SQL querya (vidi docs.mongodb.com/manual/reference/sql-comparison/). Ključna prednost je fleksibilna shema - koja ti vjerojatno ne znači ništa ako imaš predefinirane tablice i ne planiraš ih restrukturirati. Vjerojatno te ne brine ni skaliranje (s obzirom da pričamo o... 4 korisnika). A pomaže li ti mogućnost izbjegavanja joinova (po pitanju performansi) i ORM-a, ne znam, ali pretpostavit ću da te trenutno ne brine ni jedno ni drugo.

Djipi kaže:


Mislim... nested tables prikaz uopće nije stvar PHP-a, nego nečeg što koristiš kao front end, zar ne?




A, gle... upravo to - localhost i root bez pass, trebalo bi raditi out of the box. Nije radilo. Dvaput sam probao (s vremenskim razmakom, na dva različita stroja, s dvije različite instalacije). Piše u manualu? Sigurno piše negdje. Ali nemam vremena za ta sranja. Ako je to ona prva, najgluplja, najosnovnija "Hello, world" stvar, a ne radi, nabijem je na q...



Pa o tome da mi treba jednostavan, rudimentarni alat kojeg mi nitko ni za koje pare ne želi napraviti (jer nitko nema vremena, odnosno ima veće poslove ili što god), a ja nemam vremena ulaziti u to sve kao da ću se time profesionalno baviti.

Ti si mi rekao da se ne radi razvoj na eksploatacijskom serveru. JA sam ti rekao da ja to znam, ali da je to rizik kojeg sam prihvatio jer će razvoj trajati vrlo kratko i sve skupo treba ostati vrlo jednostavno.



Gdje si pročitao da tako radim, odnosno da tako programiram? Upravo obratno. Napisao sam da - kad sam god uzeo nešto što je netko drugi napravio da bi uštedio vrijeme, ispalo je da sam više vremena potrošio ispravljajući tuđa sranja, nego što bi potrošio da sam napisao sam, from scratch. Zato to ne radim.



Sad ti podrazumijevaš da ja ne znam što radim zato što sam svjesno i promišljeno odlučio da ću raditi to na takav način.



Upravo bih ga bagerom presjekao, a krampom i lopatom imam puno bolje izglede da to izbjegnem.

smayoo kaže:


Nope, krivo, MAMPOV defaultni db user je root i password je root.

Dodatno ako imaš koliziju sa macovim apacheom / mysqlom možeš promeniti port za mamp ili isključiti macove defaultne mysql i apache.

Ili ubiti defaultne servise sa apachectl itd.

Ili ... u duhu tvog načina rada ... podesi nativne apache, mysql i php da rade u željenom folderu.