Ve výchozím nastavení jsou jako PHP zpracovány soubory s příponou .php .phtml .inc .php3.
Soubory phps jsou zobrazeny jako zvýrazněný zdrojový kód PHP.
Toto nastavení lze změnit přes .htaccess AddType.

PHPerror2mail nemění error_reporting, pokud má APP nastaven např E_ALL, budou v logu i notice apod. Je na APP nastavit si odpovídající error_reporting a non-fatal řešit přes error handler. Primární účel PHPerror2mail je reportovat fatal errors, které nedojdou k error handler.

1. Lze použít
   1. PHP funkci mail()
   2. SMTP připojení na localhost
   3. autentizované připojení na smtpc.unihost.cz
2. mail() předá zprávu odpovídajícímu mail serveru pro www.
3. Mail server nepřijme zprávu pokud odesílatel From není platná mail adresa nebo skutečný odesílatel Return-Path není v doméně registrované pro odesílající www server.
4. Mail server nepřijme zprávu pro více než 30 příjemců.
5. Limit poslaných zpráv je 1msg/1sec, tento limit se při velkém množství zpráv zvyšuje.
6. Mail server může mít základní spam filtr, který má zabránit odesílání spamu z www serveru. Spam filtr by neměl propustit zprávy, které by jiné mail servery označily za jednoznačný spam.
7. Spam filtr (pokud je zapojen) notifikuje odesílatele zprávy která je špatně formátovaná (obvykle BAD_HEADER).

Logy najdete v adresari log (jedna uroven nad wwwroot) a jsou dva

• mail.log = emaily prijate do fronty
• smtp.log = predani na cilovy SMTP server

Obsahuji log pro emaily za dnesek.
Frekvence generovani je kazdych 30 min.
Za predchozi dny budou dostupne (rotovany) s ciselnym sufixem.

Technicky, jake emaily budou v tomto logu

• poslano pres PHP funkci mail() nebo SMTP localhost
• message-id je …@[www.]domena.tld
  napriklad …@unihost.cz nebo …@www.unihost.cz
• zatim nemusi zahrnovat 3d (napriklad faq.unihost.cz), pokud message-id nevyhovuje predchozimu. doresime nekdy pozdeji.

To je možné, ale existuje několik limitů, které jsou nastaveny kvůli ochraně před rozesíláním spamů ze zneužitelných formulářů apod.
Viz Proces odeslání mailu z www a omezení.
Dále limit přijatých zpráv cílových mail serverů od našeho serveru. Tento limit je závislý na třetí straně a obvykle není zveřejněn (například seznam.cz).
Tzn zprávy budou vloženy do fronty a pokud neexpirují, budou v čase odeslány-doručeny. K expiraci zprávy ve frontě - prohlášení za nedoručitelnou, dojde po 48 hod, v případě odmítání cílovým mail serverem po 24 hod.
Některé mail servery, například seznam.cz, mohou pro větší mailingy vyžadovat DKIM nebo SPF, viz Seznam.cz Email zpřísňuje svoji antispamovou politiku.
Centrum.cz - Pravidla pro rozesílání většího objemu zpráv
Seznam.cz - Posílání hromadných zpráv

V souladu s § 7 zákona č. 480/2004 Sb., o některých službách informační společnosti a o změně některých zákonů ve znění pozdějších předpisů (dále jen ZIS)
a praxí Úřadu pro ochranu osobních údajů, který při šetření stížností požaduje

• prokázání zdroje elektronické adresy - emailu
• prokázání souhlasu se zasíláním obchodních sdělení (dále jen souhlas), datum a způsob získání, IP adresa z které byl udělen souhlas
• plnění požadavků ustanovení

Požadujeme aby každá zpráva = obchodní sdělení, měla tyto náležitosti v textové i HTML podobě (pokud je dotyčná podoba použita. Obecně v každé podobě zprávy.)

• jednoduchý způsob odhlášení (= odvolání souhlasu) ze zasílání obchodních sdělení, § 7 bod 3. Například
  Pokud si již nepřejete dostávat obchodních sdělení od naší firmy, klikněte zde pro odhlášení.
• označení jako obchodní sdělení, § 7 bod 4. Do patičky uveďte všechny níže uvedené náležitosti
  • totožnost odesílatele obchodního sdělení identifikovaný obchodním jménem a adresou www stránek
  • IP adresa z které byl vysloven souhlas
  • datum a čas kdy byl vysloven souhlas

v libovolné formulaci vyhovující právním předpisům
Tato zpráva je obchodním sdělením společnosti Moje Firma s.r.o.,
které Vám bylo zasláno na základě vysloveného souhlasu na www.mojestranky.dom
z IP: 1.2.3.4
datum: 1.1.2000 11:39

• reply-to je platná emailová adresa § 7 bod 4 c

V případě nesplnění těchto smluvních podmínek podložených právními předpisy, si vyhrazujeme právo - s ohledem na náročnost řešení stížností a možného negativního dopadu na naše další zákazníky - okamžitého smazání emailů vykazujících znaky obchodního sdělení.

Doporučujeme také do odkazů apod umístit jednoznačný identifikátor příjemce, například hash emailu nebo ID, který umožní vyřadit email příjemce z databáze v případě stížností na spam. Ve většině stížností je totiž email příjemce a Message-ID odstraněno.

Reference:

• § 7 zákona č. 480/2004 Sb. - o některých službách informační společnosti a o změně některých zákonů (zákon o některých službách informační společnosti)
• článek Obchodní sdělení: bez předchozího souhlasu to nejde

Pokud emaily odesílané z našich www serverů jsou označovány jako SPAM a ve From použijete email uživatele/zákazníka např ja@gmail.com, je to v pořádku - součást globální SPAM ochrany (nikoliv pravidlo pouze na UniHost, ale na mnoha dalších serverech v Internetu). Některé domény mají bezpečnostní politiku, že jejich emaily nemůžou odcházet z libovolného serveru, pouze z jejich serverů, jako ochrana před rozesíláním SPAMu z cizích serverů s uvedením emailu From v jejich doméně.
Pravděpodobně v hlavičce emailu X-Spam najdete score
2.8 NOTVALID_GMAIL Claims to be from gmail.com but is not
Řešením je uvádět ve From adresu domény aplikace a do Reply to uvést požadovaný email.
Při uvádění emailu uživatele/zákazníka do From nemusí být také zpráva doručena kvůli DKIM nebo SPF. Proto je vhodné se tomuto v současné době vyhnout.

Rád bych použil html2ps, ale spadne mi na PHP memory limit: Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes).
Dle testování (PHP 5.2.12, html2ps 2.0.43, 2010-02-02) pro 22K stránku + 220K media potřebuje 85M RAM. Navýšení RAM pro www je možné, kontaktujte Vašeho obchodníka nebo podporu.

Licence PDFlib Lite neumožňuje použití na webhosting serveru, viz kapitola 4 PDFlib in Hosting Environments. Lze použít demo licenci (make demo stamp across all generated pages). Je na zákazníkovi aby si zaplatil běžnou licenci (795€ 2010-07-12).

Lze použít knihovny (class) například: FPDF, R&OS pdf …
Pokud víte o jiné která u nás funguje, dejte nám vědět.

Obvykle ale aplikace neuvádí důvod a žádný důvod k tomu obvykle není, vyjma lenosti vývojářů. Majorita webhostingu, z důvodů zajištění bezpečnosti, běží v safe-mode. Berou toto vývojář(i) dané aplikace na zřetel, nebo o tyto uživatele nemají zájem?
Safe-mode nijak neomezuje běžnou webovou aplikaci. V případě nasazení SElinux může být web aplikace/uživatel mnohem více omezována.
Na našich serverech je safe-mode jedním z bezpečnostních prvků, tak aby celek zajistil maximální možnou bezpečnost, kterou všichni uživatelé sdíleného webhosting serveru vyžadují. Na našich serverech nevidí uživatel na systém - aby se nemohl snažit o průnik, získání plných práv - ani na ostatní uživatele - aby nemohl číst jejich data, to je naše priorita.
Směrem k PHP6 je safe-mode zapovězen a protože udržujeme na serverech aktuální verzi PHP, budeme to akceptovat. Ale v současné době je pro PHP lepší-bezpečnější provoz se safe-mode.
Aplikace které opravdu potřebují safe-mode můžeme provozovat jako VPS. Budeme rádi pokud nás budete kontaktovat. Nebo v případě většího zájmu můžeme zřídit PHP server se safe-mode off, ale ohledně bezpečnosti jste byli varováni.

Čtení anebo zápis do adresáře je hodně pomalý, mám v něm více souborů.
Pokud adresář obsahuje více než 50.000 souborů (údaj se může v různých zdrojích lišit, dle použitých disků, filesystému, testované operace, apod), je stat na adresář náročný, přitom je nutné ho provést při každém přístupu pokud není synchronizovaný v cache. Obvyklým řešením je rozdělit soubory v tomto adresáři do více pod-adresářů dle zvoleného klíče, např dle přiděleného id [0-9] nebo názvu [a-z]. Tento přístup používá například PHP pro ukládání session na filesystém viz dokumentace session.save_path (There is an optional N argument to this directive that determines the number of directory levels your session files will be spread around in.).
Pro představu, načtení obsahu na server class disk poli

• ke strukturovaným datům 80.000 souborů = 0.049s
• jeden nafouklý adresář 500.000 souborů = 11.687s

Connect na Mysql 4.0 (mysql40.unihost.cz) databáze z

• PHP 5.3 (ww2.unihost.cz) není možný přes extensions mysql ani mysqli: Connecting to 3.22, 3.23 & 4.0 is not supported. Server is 4.0.27-log
• PHP 5.2 bez problémů
• PHP 4 (ww1.unihost.cz) bez problémů

Connect na Mysql 5.[1-5] z PHP 4 i 5 je bez problémů.

V rámci session nejsou při některém requestu přístupná _SESSION data - vrací prázdné Array. Později zase ano - bez ztráty dat. Session_id se nezmění. Problém bude na straně PHP 4 (Apache modul) - po přesunu web aplikace na PHP 5 server problém vždy přestane. Session handler je standardní file, file existuje, obsahuje data a má správná práva. Je tedy divné, že PHP jej občas nepřečte (testováno i s session_write_close). Error reporting nic nehlásí.

možností je mnoho, dvě nejpoužívanější - seřazeno od nej

wwwroot umístit do výchozího adresáře domena.tld/www/web/
a knihovny (například framework) do adresáře o úroveň výš - například domena.tld/www/inc/
Pak je inc adresář nezobrazitelný z webu přímo.

Pokud je celý web (veřejné www i privátní knihovny) nahrán do výchozího adresáře domena.tld/www/web/ pak přes rewrite a .htaccess nastavit například

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ www/index.php/$1 [L]

V tomto případě je potřeba ještě zohlednit umístění statického obsahu css, img, js, …
A do privátních adresářů nahrát .htaccess

Order Allow,Deny
Deny from all

Pro adresáře kam uživatelé mohou nahrávat soubory (např avatars) je vhodné zakázat spuštění PHP. Pak nespustí škodlivé skripty například pro rozesílání spamu. Do adresáře nahrajte .htaccess s obsahem:

# zde nemaji php scripty co delat, jde nejspis o podvrzene viry, zakazat
<FilesMatch "\.(php3?|phtml|inc)$">
  Order Deny,Allow
  Deny from All
</FilesMatch>

// přes SSL
var_dump(imap_open("{imap.unihost.cz:995/pop3/ssl}", $user, $heslo));
var_dump(imap_open("{imap.unihost.cz:993/imap/ssl}", $user, $heslo));
// resource(4) of type (imap)
 
// přes TLS
var_dump(imap_open("{imap.unihost.cz:110/pop3/tls}", $user, $heslo));
var_dump(imap_open("{imap.unihost.cz:143/imap/tls}", $user, $heslo));
// resource(4) of type (imap)
 
# 25.2.2014 testováno a již není nutné
# novalidate-cert je nutný přestože certifikáty jsou validní a podepsané cert autoritou, kvůli akceptování kořenového certifikátu CA.
# unable to get local issuer certificate: /C=US/O=GeoTrust, Inc./CN=RapidSSL CA (errflg=2)

Testováno na PHP 5.3.9, 5.3.10, 5.3.28. Dokumentace imap_open.

v FPM verzi neexistuje $_SERVER['REDIRECT_URL'] narozdíl od Apache PHP module.
Naivní způsob nahrazení

$REDIRECT_URL = (strpos($_SERVER['REQUEST_URI'], '?') ? substr($_SERVER['REQUEST_URI'], 0, strpos($_SERVER['REQUEST_URI'], '?')) // obsahuje QUERY_STRING
:  $_SERVER['REQUEST_URI']);

Pro Apache HTTP Basic Authentication v FPM verzi neexistuje $_SERVER['REMOTE_USER'] narozdíl od Apache PHP module. Ale je zde $_SERVER['REDIRECT_REMOTE_USER'] a také $_SERVER['Authorization']. Testováno na 5.5.21 a 5.3.21.

PHP běžící jako FPM nečte upravené PHP conf z .htaccess (například php_flag short_open_tag on), ale z .user.ini.
Naopak uvedení php_flag v .htaccess vede k HTTP/1.1 500 Internal Server Error,
v HTTP error logu (ISPA = HTTP debug log) pak chyba:
[alert] … .htaccess: Invalid command 'php_flag', perhaps misspelled or defined by a module not included in the server configuration

Hodnoty jsou cached by PHP: user_ini.cache_ttl controls how often user INI files are re-read. The default is 300 seconds (5 minutes).
Správné použití je tedy

# .user.ini
short_open_tag=on
max_input_vars=2000

• Hardening WordPress
• OWASP Wordpress Security Implementation Guideline