Jump to content
php.lv forumi

duncanf293

Reģistrētie lietotāji
  • Posts

    16
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

duncanf293's Achievements

Newbie

Newbie (1/14)

  1. Vispār šis forums kaut kā baigi kluss pēdējā laikā. Kur tagad PHP programmētāji aprunājas savā starpā?
  2. Gan jau, ja skola būs, tad būs attālināti. Bet nu kas to lai zin.
  3. Šajā gadījumā jautājums nav par to kā to tehniski izdarīt (variantu ir daudz) - jautājums ir par to vai tagad mēs uzskatām jebkādu PII datu kriptēšanu par labo praksi un daram to "by default" pat tad, ja klients neprasa. Nav jau tā, ka veidotos kāds milzīgs overhead kodā dēļ tās PII kriptēšanas... Visiem lielākajiem FW ir tāds vai citāds package, kas procesu padara +- nesāpīgu.
  4. Tā nav gluži taisnība, kriptēšana ir pieminēta pat vairākas reizes. Tas ir sīkāk izķidāts šajā rakstā: https://www.i-scoop.eu/gdpr-encryption/ Tomēr nav strikti minēts, vai pietiek ar visas datubāzes disk-level encryption, vai arī rekomendē kriptēt individuālus laukus. Šajā stackoverflow jautājumā (nav gan diez ko daudz atbilžu, no kā izvēlēties), iesaka ne-kriptēt email lauku (dēļ login) bet kriptēt visu pārējo (first name, last name, address) - https://stackoverflow.com/questions/50579646/should-i-encrypt-the-entire-database-or-just-fields-within
  5. Tas, ko tu ielinkoji, manuprāt ir disk-level encryption, kas pasargā pret scenāriju, kur kāds datucentra darbinieks nospertu SSD disku. Mans klients savukārt runā par scenāriju, kur kāda trešā puse iegūtu mūsu datubāzes dumpu. Tādi precedenti citām kompānijām, protams, ir bijuši. Ja PII lauki datubāzes saturā būtu kriptēti, tad tas būtu... mazliet labāk. Var argumentēt, ka gadījumā, ja hakeris ir atradis piekļuvi datubāzes dumpam, tad vienlaicīgi ir atrasta piekļuve arī servera failu sistēmai un līdz ar to encryption key iekš .env faila. Tādā gadījumā kriptēšana bijusi bezjēdzīga. Tomēr izskatās, ka ir kompānijas, kas iet šādu ceļu. Tiem Laravel package kājas no kaut kurienes aug. Lai veiktu user loginu, nav jādekriptē visi ieraksti. Populāra metode ir atsevišķā indeksētā datubāzes laukā glabāt e-pasta hash un login brīdī meklēt pēc tā.
  6. Klients pieprasa, lai datubāzē tādi PII (personally identifiable information) lauki kā email, first_name, last_name un address glabātos nevis plaintext formā, bet būtu kriptēti. Tas tiek pamatots ar GDPR prasībām. Pēc manas saprašanas GDRP kontekstā šāda kriptēšana ir rekomendācijas līmenī un nav dotas specifiskas vadlīnijas ne kriptēšanas algoritmiem, ne arī encryption key drošai uzglabāšanai. Vieta interpretācijai. Vai esat saskārušies ar šādu prasību, kā to risinājāt? Konkrēti lietoju Laravel FW, tāpēc ir doma paņemt kādu package, piemēram, šo: https://github.com/betterapp/laravel-db-encrypter Iekšēji package izmanto Laravela Crypt fasādi, kas paņem encryption key no .env faila. Modeļos var norādīt, kurus laukus vajag kriptēt, pārējie paliks plaintext. Teorētiski ar šo būtu jāpietiek?
  7. Domu laikam sapratu, bet dažas lietas jāprecizē. Vendor ielikšana atsevišķā mapē pati par sevi diez vai kaut ko dod. Tas ko tu laikam gribēji pateikt ir, ka "app-vendors" ir iekopēts konteinerā ar COPY iekš Dockerfile, nevis pieslēgts caur volume? Caur volume pieslēgts tikai "app", jeb development laikā maināmais source kods? Tas varētu tiešām būt efektīvi.
  8. Novēroju apmēram šādu uzvedību - ja neesmu kādas 5min refrešojis lapu, tad pēc pirmā refreša load time būs lēns, kādas 3-5 sekundes. Uzreiz pēc tam atkārtoti spiežot refresh, ir labāks load time, varbūt 1-2 sekundes. Ja atstāju mierā uz 5min vai ilgāk, tad pirmais refresh atkal aizņem 3-5 sekundes un atkārtoti refreši biški mazāk, bet tāpat ilgi. Ok, šī varbūt nav lielākā problēma pasaulē, bet tomēr diezgan kaitinoši. Šķiet specifiski MacOS, jo uzliekot uz produkcijas linux servera, ātrdarbības problēmas vairs nav.
  9. Diemžēl nekādu īpašu efektu no "delegated" mount tipa nejūtu
  10. Nē, nav mēģināts. Strādā? Tā nav īsti tāda informācija pie kuras tu nonāc tajā posmā, kad vēl tikai mācies pirmos soļus ar Docker. Pamēģināšu palietot "delegated" kādu brīdi. Third-party risinājumus 0.x versijas stadijā gan ne pārāk gribas lietot, bet paldies par ieteikumu.
  11. Hmm, lokālajā dev vidē faili nekad nebūs pa tiešo uz docker image... Tā kā faili tiek visu laiku laboti, rakstīti klāt jauni, dzēsti utt. Tad projekta mape vienmēr ir pieslēgta caur mounted volume. Tas variants ko Tu aprakstīji ir produkcijā, bet tur jau arī MacOS nekad nebūs.
  12. Sveiki, esmu sācis lietot Docker un nevaru nepamanīt, ka uz MacOS tas darbojas diezgan lēni. Vispārīgi saprotu tam iemeslus - MacOS un Windows vide nav linux - tur ir vajadzīga vēl viena smaga/lēna abstrakcija. Izskatās bēdīgi, jo jaunam Macbook Pro ar i9 procesoru vajag kādas 2 sekundes, lai apstrādātu vienu web requestu. Tur pat nenotiek nekas resursu intensīvs, nav pat savienošanās ar datubāzi. Tikai parasta skata renderēšana. Salīdzinājumam švakāks DELL laptops ar linux burtiski lido. Vai tam ir kāds reāls risinājums? Bieži dzirdu par to cik Docker ir labs, cik plaši to izmanto utt, bet nu kā tad to sūdu reāli izmantot ja sakarīgs ātrums ir tikai Linux vidē? Paldies!
  13. f***k, jā, paldies. Tā kā 80 automātiski ir exposed, tad baigi viegli aizmirst, ka 443 nav exposed.
  14. Palīgā, es nemāku Docker! Mēģinu lietot pieredzējušākiem docker lietotājiem iespējams pazīstamo jwilder/nginx-proxy (https://github.com/nginx-proxy/nginx-proxy) Mērķis ir standarta darbība - lokāli palaist nginx, kurš visu http trafiku uz porta 80 pārsūta uz https. Ar self-signed sertifikātu. Nginx konfigurācijas fails un self-signed sertifikāti visticamāk ir pareizi, jo, ja nelietoju nginx-proxy vispār nemaz un vienkārši pieslēdzu savu nginx pa taisno host mašīnas portiem 80 un 443 - tad viss strādā. Savukārt, ja mēģinu vēl priekšā pielikt šo nginx-proxy, tad browserī atpakaļ saņemu 502 Bad Gateway. It kā izdarīts viss, kas minēts dokumentācijā: 1. Kā environment mainīgie konteineram padoti VIRTUAL_HOST=mydomain.local, VIRTUAL_PROTO=https and VIRTUAL_PORT=443 2. Pašam nginx-proxy konteineram kā volume padota mape ar .crt un .key sertifikātiem Un tomēr ir tas 502 Bad Gateway. Nginx error logs ir uzlikts uz "debug" līmenī, bet tajā logā tāpat nekas neiekrīt. Neredzu papildus iespējas, kā debugot. Nginx config fails: server { listen 80; return 301 https://$host$request_uri; } server { listen 443 ssl; listen [::]:443 ssl ipv6only=on; ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt; ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key; error_log /var/www/storage/logs/nginx-error.log debug; # tukšs access_log /var/www/storage/logs/nginx-access.log; # tukšs # other things... } docker-compose.yml: version: '3' services: nginx: build: context: ../ dockerfile: ./docker/nginx/Dockerfile environment: - VIRTUAL_HOST=mydomain.local - VIRTUAL_PROTO=https - VIRTUAL_PORT=443 volumes: - ${BASE_PATH}/public:/var/www/public - ${BASE_PATH}/storage/logs/nginx-error.log:/var/www/storage/logs/nginx-error.log - ${BASE_PATH}/storage/logs/nginx-access.log:/var/www/storage/logs/nginx-access.log self-signed sertifikātu ģenerācijai lietotā komanda: openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt -subj "/"
×
×
  • Create New...