spameris

Par tēmu lūdzu kungi :)

Runa ir par to ja WEB uzhako, tad var dabūt visus lietotāja datus zinot tikai FB id. Tb WEB sūta uz DB SOAP pieprasījumu ar FB ID un DB atgriež usera datus. Manā gadījumā tas nederēs, man jāzin DB pusē, vai kāds hakeris nesūta feiku pieprasījumu ar FB ID nemaz neautorizējies FB. Tādēļ es domāju validēt šo te FB tokenu no DB puses.

problēma ir ar 4) Atrodi savā datubāzē registrētu leitotāju ar šādu FB ID un autorizē savā sistēmā jo īsti nevaru ticēt WEB, jo negribu atgriest datus tikai pēc FB ID jo WEB neuzticos. gribu lai WEB sūtot pieprasījumu DB iekļautu arī lietotāja tokenu, tad DB sūtītu uz FB jaunu pieprasījumu un pārbaudītu, vai šādam tokenam atbilst konkrēts FB ID. tas tamdēļ, ka īsti WEB nedrīkstu uzticēties un jautājums ir vai ar manu domu tur viss ir OK.

Sveiki, tātad ir sistēma, nu saukšu viņu par DB kurai slēdzas klāt caur SOAP un ir WEB lapa kurā ievadot lietotāju un paroli pieprasījums tiek pārsūtīts uz DB un ja ar lietotāju un paroli viss OK, tad cilvēks ielogojas un tiek pie visādiem saviem datiem. Uzdevums ir šiem te lietotājiem iespēju sasaistīt savu kontu ar facebook. Nu idejiski lietotājs dabū savu FB tokenu, WEB dabū FB lietotāja ID un šos ten esošos lietotājus DB sasaistam pēc facebook ID. Gribētu saprast vienu lietu, kā pareizi risināt. Ir tā ka WEB pusei tā īsti es nedrīksu uzticēties un atķļaut WEB serverim tikai pēc FB ID atgriezt lietotāja datus, jo piemēram ja kāds uzlauž to WEB tad diezgan brīvi varētu zinot tikai FB ID iegūt lietotāja datus. Kautkādā veidā vajadzētu DB validēt ka tiešām šis te lietotājs ir autorizējies FB. Mana doma ir tā, kad WEB pieprasa lietotāja datus no DB, tad kopā ar SOAP pieprasījumu tiek nodots arī lietotāja tokens un FB ID, un DB vēlreiz sūta pieprasījumu uz FB API ar šo te tokenu un pieprasa lietotāja ID, ja lietotāja ID sakrīt un nav nekādu kļūdu no FB puses, tad lietotājs ir autorizējies FB. Domāju ka mans gadījums nav nekas unikāls un negribas nekādu divriteni izgudrot pa jaunu. Kāda ir prakse šādos gadījumos ? Pats es to WEB nekodēju, bet vajag saprast kā pareizi droši tur visu sataisīt.

Paldies!

Sveiki, varbūt varat nosaukt lūdzu teiksim LV top 5 web izstrādes kompānijas, kas kodē PHP sadarbībai ilglaicīgam projektam. Nu ar vērā ņemamu portfolio. Vajadzīga kompānija freelancers nederēs.

Man šķiet ka diezgan garām visu esi sapratis Roze. Iedomājies ka hostē kautkādas dažas WordPress lapas un vienu no tām uzlauž un tur parādās kautkādi fraud linki, pat ne uzlauž varbūt komentāros, vai uzreiz 5 min laikā jāizdzēš visi dati tb virtuālā mašīna, vai jāapstādina mašīna un jābrīdina klients ? Manā gadījumā tur bija kautkādi linki salikti vinā gadlīgi nenopietnā lapā, lai gan 1h laikā reaģēju.

Kopējas visi dati uz digitalocean. Izskatās jau labi, tas ssdapp.com jau ar izskatījās pieklājīgs, nu lapa vismaz smuka un viss strādāja :)

Nav man nekāda sakara ar nevēlamu epastu sūtīšanu :) . Stāsts ir pat to megaurl.it par ko te raksīju, ka no īsa url var uztaisīt garu. Cik sapratu kāds bija ielicis kautkādus fraud linkus tajā megaurl.it, kāds pasūdzējies un... nah visu vps uzreiz izdzēsa, bez brīdinājuma bez kā. Lai gan tur tajā saitā manā nekā nelegāla nebija.

ak jā laikam jau šeit topiku vajag pārvietot http://php.lv/f/forum/35-hostinga-nov%C4%93rt%C4%93jumi-un-atsauksmes/

Izdomāju iepostēt savu bēdu stāstu varbūt labāk paliks :) Sameklēju VPS http://ssdapp.com/linux vps par 9EUR mēnesī, itkā viss ok strādā līdz vakardienai. Skatos vakar vairs nevaru pieslēgties šai lapai. Ieeju viņu vadības panelī, skatos mans VPS suspendods, taisu ticket, prasu kas par lietu. Šie atbild, tādā un tādā vietā uz viena no manām lapām links uz scam kautkādām vietām. Saku no problem izvākšu, tikai ieslēdziet kasti atpakaļ. VPS tad šie ieslēdza bet pilnīgi tukšu, visi dati pazuduši. Prasu lai atgriež datus, šie atbild datu atgriešanu piedāvāt nevarot.... WTF, ja arī kautkādos komentāros web saliktu scam linkus, dzēšam visu mašīnu ārā, iepriekš nekādu brīdinājumu nekā. Izklausās neticami, bet nu no šī kantora kā no uguns jābēg, zinu ka par 9EUR nevar gaidīt tur top servisu, bet nu klientu datus šādi dzēst ārā nedrīkst.

Nu runa nav par web servera pieprasījumiem, bet par cilvēku pie datora, neticu ka PI var tikt ar to galā. Un vispār arī nevienu vārdu neteicu, ka strādā lēni tur kautkas. Problēma ir piemēram ar php wincache shared memory lokiem, kas uzrodas randomā, nesaprotamiem IIS FastCGI interfeisa krešiem.

Jā bet nu IIS+php būs maz lietotāju, kā arī apache+php+win būs vēl mazāk lietotāju. Un ja ir specifiskas specifiskas problēmas tad ir sarežģiti viņas risināt, dēļ praktiski neeksistējošās lietotāju bāzes šādiem setupiem. Un IIS+php gadījumā MS ubersertificēti speci ar neko daudz nepalīdz. Ar IIS+.net jau viss ir OK, tikai šķiet ar php nav tik labi. Ja nemaldos tas ISAPI ir deprecated. Nu ar kodu jau ar šķiet viss vairāk, vai mazāk OK, jo nav jau problēmas ar ātrumu, bet kā jau minēju ar paša IIS+php stabilitāti.

Paldies par atbildēm! Jā vajadzēs kādu daļu SQL vaicājumu pārrakstīt, bet konsultējoties ar izstrādātājiem to var izdarīt abām pusēm apmierinošā laikā. Viena no lielākajām problēmām kā jau minēju ir IIS+php stabilitāte pie noslodzes. Manuprāt WIn+apache+php, vai linux php ar mssql draiveri ļoti liela iespēja ka problēmas būs līdzīgas. Tādēļ gribas setupu, kuru ir pārbaudījuši ļoti daudz serveri un tas būtu php+apache,vai nginx+mysql. Tam saitam var saskriet ~6 stundu laikā līdz 45k apmeklējumu nu tas nav bieži, bet ir momenti kad serverim ir ko svīst.

Cik nu man sanācis ar linux un php darboties, nu jākompilē jau ļoti reti tomēr, kas ir arī labs arguments, ja nav vajadzība pēc kādas ļoti specifiskas libas, vai liba versijas. Vienīgais ko pēdējā laikā esmu kompilējis bija mongodb draiveris php, bet nu tur viss bija vienkārši.