Aleksejs

Spriežot pēc nosaukuma, tajos skriptos dikti vajadzīga "iekšējā bezgalīgā govs" ...

15 best free opensource eCommerce platforms

http://anologue.com/

Toties glabājot DB ir vienkāršāk organizēt daudz smalkākas piekļuves tiesības (kuram no web-aplikācijas lietotājiem, kas ir pieejams), nekā standarta failu sistēmā. Katrai pieejai ir savi plusi un savi mīnusi.

Saliec atstarpes un semikolus: <? while($row = mysql_fetch_array($result)){$useris = $row['name'];$skaits = $row['posts']; ?> <td style="text-align:center"><?= $useris; ?></td> <td style="text-align:center"><?= $skaits; ?></td> Panelis parādās... tādēļ, ka tas neatrodas if sadaļā - līdz ar to tas tiek parādīt neatkarīgi no tā vai ir ielogojies vai nav...

Un kāds būtu šī errora teksts?

1) Ne obligāti 2) Jā

http://chat.nodejs.org/

Tev ir jātaisa atsevišķs skripts, piemēram, bilzuks.php, kuram padod bildes identifikatoru un kurš tad attiecīgi pieslēdzas datu bāzei, dabū BLOBu, uztāda pareizos headerus 'image/jpg', piemēram. un tad izvada šo bināro informāciju. tātad lapā tas izskatītos: <img src="/serverscripts/bilzuks.php?id=124"/>

Tātad kļūda SQLā. Pārveido 5. rindiņu: $result = mysql_query("SELECT * FROM news") or die('SQL kļūda '.mysql_error()); P.S. Cerams, ka "a2965386_rg","losw_dev_blog" nav īstie username/password...

Visticamāk teksta redaktors, kurš saglabā UTF-8 kodējumā ar BOM Paņem teksta redaktoru, kurš prot saglabāt arī bez BOM, piemēram Notepad++ (neticu, ka ne windows vidē Tev ir šāda problēma ;) )

Pieejamās lokāles mēdz būt norādītas failā: /usr/share/i18n/SUPPORTED man uz xubuntu ar lvv saistītās ir šādas: lv_LV.UTF-8 UTF-8 lv_LV ISO-8859-13

HMVC an introduction and application

Approved

Lielākoties, tas tiek darīts, pārbaudot, vai ir tavas lapas referers: php variantā - $_SERVER['HTTP_REFERER'] atbilst sagaidāmajam... webservera līmenī cīņa aprakstīta te: http://www.askapache.com/htaccess/anti-hotlinking-mod_rewrite.html

Ja netiek izmantoti.... tad neliec tos lapā. Man tās reizes, kad atvēra, atvēra ~5 sekundēs (atskaitot tos monitorus, kuri tā arī nepārstāja lādēties). Varbūt tev web servera konfigurācijā uzstādīts ļoti mazs vienlaicīgo pieslēgumu skaits...

Kuru no šīm lietām tu sauc par kodēšanu? Autentificēšanas procesā šajā gadījumā jāgriežas vienu reizi pie DB pie tokena izveidošanas. Pēc tam, var tikai pārbaudīt vai: a) veiksmīgi var atšifrēt b) atšifrētajai daļai ir pareiza hmac kontrolsumma. Līdz ar to nav jāglabā nekāds ID datu bāzē un pie datu bāzes nav jāvēršas. Konkrētais piemērs bija demonstrācija "hardened stateless cookies", kura mērķis bija parādīt, kā var iztikt bez jebkādu sesijas datu glabāšanas serverpusē. Ar tiem randomā ģenerētajiem stringiem... Manuprāt ir problēma, ka vēl jādomā viņu iztīrīšanas process no datu bāzes, jo noteikti būs gadījumi, kad lietotājs izdzēš visus cepumus, bet neveic normālu "logout" procedūru...

Vienkārša hash() vietā labāk būtu izmantot hash_hmac(): Piemēram kā autentificēšanās sistēmā, kuras piemēru devu: auth_common.php failā function maketoken($uid,$parole,$autorenew,$expire,$info){ $key = pack('H*','86b6de905bbee18b3425f7e5974c1cad7e24ec06a707a2766c5988c20ebc7337');//šī ir slepenā šifrēšanas atslēga HEX formā, NOMAINĪT OBLIGĀTI!!!! $hmac_key = pack('H*','8412789462918462123861789234612378964123763412781273467252347564735');//šī ir slepenā HMAC atslēga NOMAINĪT OBLIGĀTI!!!! $td = mcrypt_module_open('rijndael-256', '', 'cbc', ''); srand(); $iv = mcrypt_create_iv (mcrypt_enc_get_iv_size($td), MCRYPT_RAND);//ja tiek izmantots Linux/BSD* tad izmantojiet MCRYPT_DEV_URANDOM mcrypt_generic_init($td, $key, $iv); $data=$uid.','.bin2hex($parole) .','.intval($autorenew).','.intval($expire). ','.ip2long($_SERVER['REMOTE_ADDR']) . ',' . bin2hex($info);//info - papildus mainīgie utt, kas jāsaglabā no vienas lapas uz otru $data=$data.',' . hash_hmac('sha512',$data,$hmac_key,false);//Pievienojam imitoaizsardzību //echo "kukijaa baazamais: $data <br>"; $data = mcrypt_generic($td, $data);//šifrējam $data = bin2hex($iv) . ',' . bin2hex($data); mcrypt_generic_deinit($td); mcrypt_module_close($td); return $data; } Šeit gan jāpiebilst, ka manis apskatītās sistēmas pamatā bija daudzkārtēja paroles hashošana, līdz ar ko funkcijai maketoken() tiek padota jau daudzkārtēji hashota parole. Un pat, ja tiktu padota parole atklātā tekstā, lietotājam cepumā visa tiek glabāta šifrēta (AES-256 CBC režīmā). Lietotājs nezina $key mainīgo un tāpat nezina $hmac_key mainīgo.

Kļudas paziņojums nozīmē, ka kaut kas nav kārtībā koda 3. rindiņā. (visticamāk 2. rindiņas beigās trūkst semikola...)

Pāris kilogrami dažādu galeriju: http://www.webappers.com/category/components/gallery/ Dažām līdzi sīks soli-pa-solim stāsts kā un kāpēc taisīta tieši tā.

ko atgriež vaicājums: SELECT `comments`.* FROM `comments`

Tomato Cart

Jo!

Piezīme: ja tiktiešām tiek izmantots FTP (bez nekādām papildus drošības fīčām), tad parole ceļo nešifrēta pa tīklu - līdz ar to dajebkas, kas ir uzstādīts starp tavu klaviatūru un servera procesoru var nolasīt šo paroli, kamēr tā tiek pārsūtīta.

tieši shell_exec() neizpildās? Varbūt ka to hostingā neļauj izmantot?