Archívum - 2011
február 11
E-mailek biztonságban
Sziasztok!
Van megvásárolt domainom. Minden megvan tehát ahhoz, hogy normális webcímem legyen és normális e-mail címem.
De elgondolkodtam: ha az e-mailjaim a tárhelyszolgáltatónál landolnak - tudom, fő a bizalom, na de manapság, na meg a lehetőség benne van - akkor ha akarja, elolvashatja a levelezést, ami nem lenne szerencsés.
Tudom, sokan úgy gondolják, kit érdekel, miért foglalkoznának vele.
De ha pár ezer előfizetője van egy szolgáltatónak, akkor ez nem olyan nehéz és ha mondjuk valamiért felkelti az egyik ügyfél az érdeklődését és nem áll erkölcsileg a helyzet magaslatán, beleolvashat céges levelekbe, amivel akár vissza is lehet élni.
Kérem, hogy azok, akik egy legyintéssel elintézik a dolgot, ne fárasszák magukat írással, mert ők azok, akik a legjobban kétségbe esnek, ha megtörténik a baj.
Engem csak az érdekel, hogyan lehet ezt technikailag elkerülni.
1. Saját szerver, saját helyen, 24 órás üzemelés mellett. Ez MÉG drága és nem is kényelmes.
2. Szerver bérlés: ez megfizethető, de jóval drágább, mint a 3. variáció és azért ez már nem olyan biztos, hiszen ott van fizikailag a gép.
3. Nem foglalkozni semmivel, a többség úgyis megússza, a tárhelyszolgáltatónál tartani a céges, időnként üzleti titkokat is tartalmazó leveleket.
Egyik se tetszik.
Az tetszene, ha a google-s e-mailt használhatnám, mert a google annyira nagy és angol anyanyelvű cég, hogy ott tényleg kicsi a valószínűsége, hogy nézegetnék a magyar nyelvű mailjaimat.
Viszont nem akarom, hogy az ügyfelek gmailos címet lássanak, mert az gagyi és nem azért fizettem tárhelyet.
Valahogy meg lehetne csinálni, hogy a céges mailra írnak, de az átirányítódik a gmailosra úgy, hogy fizikailag sosem landol és megy át a tárhelyszolgáltatómon, és amikor válaszolok, akkor megint a céges mailt lássák?
■ Van megvásárolt domainom. Minden megvan tehát ahhoz, hogy normális webcímem legyen és normális e-mail címem.
De elgondolkodtam: ha az e-mailjaim a tárhelyszolgáltatónál landolnak - tudom, fő a bizalom, na de manapság, na meg a lehetőség benne van - akkor ha akarja, elolvashatja a levelezést, ami nem lenne szerencsés.
Tudom, sokan úgy gondolják, kit érdekel, miért foglalkoznának vele.
De ha pár ezer előfizetője van egy szolgáltatónak, akkor ez nem olyan nehéz és ha mondjuk valamiért felkelti az egyik ügyfél az érdeklődését és nem áll erkölcsileg a helyzet magaslatán, beleolvashat céges levelekbe, amivel akár vissza is lehet élni.
Kérem, hogy azok, akik egy legyintéssel elintézik a dolgot, ne fárasszák magukat írással, mert ők azok, akik a legjobban kétségbe esnek, ha megtörténik a baj.
Engem csak az érdekel, hogyan lehet ezt technikailag elkerülni.
1. Saját szerver, saját helyen, 24 órás üzemelés mellett. Ez MÉG drága és nem is kényelmes.
2. Szerver bérlés: ez megfizethető, de jóval drágább, mint a 3. variáció és azért ez már nem olyan biztos, hiszen ott van fizikailag a gép.
3. Nem foglalkozni semmivel, a többség úgyis megússza, a tárhelyszolgáltatónál tartani a céges, időnként üzleti titkokat is tartalmazó leveleket.
Egyik se tetszik.
Az tetszene, ha a google-s e-mailt használhatnám, mert a google annyira nagy és angol anyanyelvű cég, hogy ott tényleg kicsi a valószínűsége, hogy nézegetnék a magyar nyelvű mailjaimat.
Viszont nem akarom, hogy az ügyfelek gmailos címet lássanak, mert az gagyi és nem azért fizettem tárhelyet.
Valahogy meg lehetne csinálni, hogy a céges mailra írnak, de az átirányítódik a gmailosra úgy, hogy fizikailag sosem landol és megy át a tárhelyszolgáltatómon, és amikor válaszolok, akkor megint a céges mailt lássák?
Google Rolls Out Two-Factor Authentication For Everyone. You Should Use It.
Kétlépcsős authentikáció a Google szolgáltatásaihoz
■ CSRF: Flash + 307 redirect = Game Over
HTTP 307-nél nem ellenőrzi a Flash a crossdomain.xml meglétét
■ HTML5-re tér át a Dojo
A Dojo a JavaScript keretrendszerek közül leginkább azzal tűnik ki, hogy widget komponenseit deklaratívan, a HTML markupban is lehetséges konfigurálni bárminemű szkript programozás nélkül. Ezt a fejlesztők nem szabányos HTML attribútumok bevezetésével oldották meg, amiért rendre bírálat érte a projektet. (A jogosság megvitatásától itt most tekintsünk el.)
február 11
Osztálybetöltési sorrend autoloader nélkül wildcard szabályokkal
Sziasztok!
Előre bocsájtom, hogy a projekt és ezzel a kérdés is meglehetősen kísérleti jellegű és önkényesen szűkre szabott peremfeltételekkel rendelkezik.
A kísérlet tárgya egy PHP-ban írt, FastCGI-t beszélni képes daemon. (Természetesen közelről sincs készen.) A probléma az osztály betöltéssel van, ugyanis azt a feltételt szabtam, hogy lehetőség szerint töltsön be minden osztályt, fájlt, stb. előre, tehát az autoloading kiesik a játékból.
Teremteni szeretnék egy lehetőséget, hogy ilyen szabályokat lehessen mondani:Ezzel viszont az a probléma, hogy a
Ötletek, amiket Tyr43ltől kaptam a probléma megoldására:
A projekt SVN repója itt található: http://svn.janoszen.com/repos/fw/trunk/framework/
A generált doksik pedig itt: http://svn.janoszen.com/docs/fw/framework/
(A kód egyelőre működésképtelen, proof-of-concept gyártása van folyamatban, pár demó kódot gyártottam benne.)
Köszönöm a segítséget.
■ Előre bocsájtom, hogy a projekt és ezzel a kérdés is meglehetősen kísérleti jellegű és önkényesen szűkre szabott peremfeltételekkel rendelkezik.
A kísérlet tárgya egy PHP-ban írt, FastCGI-t beszélni képes daemon. (Természetesen közelről sincs készen.) A probléma az osztály betöltéssel van, ugyanis azt a feltételt szabtam, hogy lehetőség szerint töltsön be minden osztályt, fájlt, stb. előre, tehát az autoloading kiesik a játékból.
Teremteni szeretnék egy lehetőséget, hogy ilyen szabályokat lehessen mondani:
\ClassLoader::import('PHP\Lang\*');
* miatt betöltött fájlban is lehet ugyanilyen szabály. Hogyan tudnám megoldani, hogy a kötelező sorrendek be legyenek tartva a betöltésnél? (pl. szülőosztály betöltése)Ötletek, amiket Tyr43ltől kaptam a probléma megoldására:
- Reflectionnel nézzük végig betöltéskor az osztályt, hogy milyen függőségei vannak. Így csak az indulást lesz lassú.
- Induláskor húzzunk fel egy autoloadert a dependenciák feloldására.
A projekt SVN repója itt található: http://svn.janoszen.com/repos/fw/trunk/framework/
A generált doksik pedig itt: http://svn.janoszen.com/docs/fw/framework/
(A kód egyelőre működésképtelen, proof-of-concept gyártása van folyamatban, pár demó kódot gyártottam benne.)
Köszönöm a segítséget.
Kiíratott tábla táblázatba tételénél hiba
Sziasztok
Valami hiba van a táblázatba rendezésnél.
A kód:Kösz a segítséget!
■ Valami hiba van a táblázatba rendezésnél.
A kód:
<?php
$kapcsolat = mysql_connect('localhost','felh','jelszo');
$adatbazis = mysql_select_db('dbnev', $kapcsolat);
$result = mysql_query("SELECT ('id','nev','felhasznalonev','jelszo','email','bemutatkozas') from users", $kapcsolat);
print"<table>";
while ($sor = mysql_fetch_object($result)) {
print"<tr>";
print_r($sor);
print"<td></td><td></td><td></td><td></td><td></td><td></td>";
print"</tr>";
}
print"</table>";
?>
Kiíratott tábla táblázatba tételénél hiba
Sziasztok
Valami hiba van a táblázatba rendezésnél.
A kód:Kösz a segítséget!
■ Valami hiba van a táblázatba rendezésnél.
A kód:
<?php
$kapcsolat = mysql_connect('localhost','felh','jelszo');
$adatbazis = mysql_select_db('dbnev', $kapcsolat);
$result = mysql_query("SELECT ('id','nev','felhasznalonev','jelszo','email','bemutatkozas') from users", $kapcsolat);
print"<table>";
while ($sor = mysql_fetch_object($result)) {
print"<tr>";
print_r($sor);
print"<td></td><td></td><td></td><td></td><td></td><td></td>";
print"</tr>";
}
print"</table>";
?>
