Jak řešíte zapínání laděnky na produkci?
- Maekoboss
- Člen | 36
Obecný problém:
Jsme vývojáři, pracující na více projektech, které vyvíjíme, spravujeme a updatujeme. Pokud se někde vyskytne problém, tak zapnutí development modu je často první krok. Při použití standardního zapnutí v bootstrapu přes IP:
$configurator->setDebugMode(array(IPs));
Narážíme na problém, že máme více vývojářů pracujících z domu, kaváren atd. Takže se případně musí přidávat IP adresy atd., což není zrovna pohodlné, takže hledáme nějaké lepší a stálejší řešení.
Jako asi nejsnažší řešení mi přijde použití cookie a v bootstrapu pak kontrola její hodnoty. Moc si nejsem jistý bezpečností tohoto řešení, ale na HTTPS by to asi mohlo být ok, tak se cookies posílají šifrovaná.
Ještě mě napadla kontrola přihlášení uživatele a jeho role v session, ale v bootstrapu se k session nedostanu, startuje se až později, nehledě na to, že identita se refreshuje z db s každým dotazem.
Jak tohle řešíte vy? Případně jaká jsou rizika přístupu přes cookie?
Díky
- joe
- Člen | 313
Mně přijde ideální mít na webu URL adresu, například example.com/develop a například po zadání nějakého hesla budu mít možnosti pro smazání cache, zapnutí laděnky apod. (což se může nastavit přes cookies/sessions). Mají tak k tomu přístup všichni, není to omezeno na IP adresu.
- Tomáš Jablonický
- Člen | 115
Na produkci laděnku nikdy nezapínáme. Vždy je vypnutá. Vše si taháme z logu a chybu si snažíme nasimulovat na lokálním počítači. Zapnout laděnku na produkci je docela amaterismus.
- Mysteria
- Člen | 797
Tomáš Jablonický: Proč by to měl být amatérismus? Naopak zapnutá Tracy na IP adresu a cookie spolu s analyzátorem logů mi u vlastních projektů šetří hromadu času. Zapnu web, mrknu na Tracy a hned vidím na čem jsem:
Na jedno kliknutí zobrazím podrobný log. Pohledem na User-Agent vyfiltruju jenom reálné uživatele. Pohledem na refferer zlikviduju různé odkazovací farmy a filtrací dle země vyfiltruju Čínu myslící si, že můj web běží na Wordpressu a plnící můj log přístupy na stránku wp-login.php. Ano, tohle by se dalo dělat i mimo produkci, ale je to práce navíc, takhle to je pro mne nejpohodlnější.
- joe
- Člen | 313
Docela by mě zajímalo, z jakého důvodu jste mi tolikrát označili příspěvek za špatný? Daná URL samozřejmě může být chráněna heslem, IP adresou a čímkoli dalším. Nevidím důvod nemít pro takové věci grafické rozhraní přímo na webu – i co se týká ladění, mazání cache a dalších užitečných věcí. (Samozřejmě by to nezapínalo laděnku pro všechny, ale jen pro přihlášeného uživatele).
- joe
- Člen | 313
@newPOPE Moc tomu nerozumím, jen jsem navrhl řešení (rozhraní), jak laděnku zapnout na živé verzi, tzn. že v kódu nebudu mít natvrdo nastavené IP adresy, protože se mohou měnit, můžou přibývat a zase ubývat. Zapnutím vývojového režimu na živé verzi nevidím nic špatného, naopak, rychle se dá reprodukovat problém, místo toho, abych projekt stahoval a reprodukoval problém na lokálu, když zrovna nemusím být u vývojového PC apod.
- Maekoboss
- Člen | 36
@joe Díky za návrh ono skrýt to za rozhraní není až takový problém, ke všem webům máme nějaký administrační systém. Problém je, že v bootstrapu ještě není vytvořený kontejner, takže není ani spuštěná session a při manuální inicializaci session v bootstrapu si s tim defaultně nette neporadí (vyhodí se výjimka, kterou jsme dál nijak nezkoumali), takže by to stejně muselo fungovat přes cookie, tudíš stejně jak jsem popisoval já, akorát bez rozhraní (na nastavení cookie stačí plugin v prohlížeči).
@Oli takže to pravděpodobně děláme „správně“ už teď.
Díky za vaše názory.