Nejste přihlášeni
Výborně, děkuji za rychlou reakci.
stejný/podobný problém: Kód chyby: sec_error_unknown_issuer na doméně vse-testy.cz. Mám tam vlastní certifikát, ale jakoby se přepne na sdílený endora a na něm je tento problém. Už se mi to stalo podruhé, poprvé jsem byl na chatu ujištěn, že to bylo výjimečné a nebude se opakovat. Tento problém omezuje řadu funkcí aplikace, neboť musím poskytovat zabezpečené spojení SSL na určité operace. Zajímalo by mě jestli se to bude nějak účinněji řešit a jaké jsou podmínky provozu a garance služeb ze strany Endory.
Dnes jsem prodloužil zákazníkovi registraci domény a plus program, pomocí uhrazení zálohové faktura, transakce proběhla OK, obdržel jsem potvrzení od banky i Endory, ale cca po 2 minutách se program změnil na FREE - přitom stále ještě platí ten původní Plus /do 14.2.2014/
doména: www.famtoys.cz
Prosím urychlenou nápravu.
Ok, zítra zkusím z práce. Je ale divné, že to na jiné doméně jde normálně. Každopádně děkuji za pomoc a rady.
Ano, vidím, Vám to tam leze hezky ten delfín :-D , já to fakt nechápu, u jiných domén jsem neměl problém a ani nyní nemám, jak jsem psal, pod stejným účtem jsem na druhou doménu nahrál bez problémů ten samý obsah.
Zkoušel jsem z jiného PC doma, zítra můžu zkusit z jiného PC v práci, jen si musím změnit povolení na IP adresy.
Už možná vidím ten problém, není náhodou nastaven nějaký limit na počet přenášených souborů? Když přenáším cca do 50 položek, tak to projde OK...stejně to tak dopadne, že to budu nahrávat po částech, už stím trávím druhé odpoledne...
To by to ale nefungovalo vůbec ne? Každopádně vyzkouším SFTP připojení.
Tam mám nastaveno 1, ale děkuji za radu. Problém musí být na doméně, ostatní domény (i pod stejným ftp účtem) mi běží upload bez problémů (soubory jsou identické, to už jsem zkoušel včera).
Nemůže vadit SSL třeba, včera jsem nahrál certifikát GeoTrust?
ve WinSCP to asi nějak pomalu pujde, sice to každou minut padá "Čas vypršel.
Kopírování souborů do vzdáleného adresáře selhalo.
Opening BINARY mode data connection for soubor.xxx", ale winSCP to pak zase naváže a jede to dál
Bezva, tak tedka mě to komplo, že mám moc připojení (6) - to budu muset asi počkat těch 30 minut, než to vychcípá co?
Ok, zkusím ještě WinSCP, ten jsem nezkoušel.
od 5 Mb do 150 Mb, jednotlivé soubory se neseknou, ale nechci nahrávat cca 5000 souborů takto. Většinou se to seklo tak po 1,5 Mb, někdy hned po pár Kb, část souborů se mi nahrát podařilo. Opět otestuji a napíšu.
Otestováno: 1,2 Mb složka s cca 10 soubory (obrázky) seknutí na 227 Kb.
Předpokládal jsem, že si to dokážete zjistit, doména vse-testy.cz, díky.
Nějak mi taky začlo blbnout FTP (většinou se po pár Kb uploadu sekne), používám Total Comanader, stejný problém i na jiných klientech FTP, dříve tento problém nebyl. Jediná změna, je že mám od včera další doménu a nefunční FTP je tudíž zásadní problém.
Restart, čekání, jiný klient, jiný uživatel ftp, jiný počítač, jiné připojení k internetu nepomohlo, víc mě nenapadá.
Předem díky za pomoc
Připojení již funguje, děkuji za pomoc.
Jen se mi rozbilo totálné kódování, ale nevadí, to už si opravím ze záloh databáze - hlavně je to moje chyba... Takže můžete považovat za vyřešené.
Přechod na PHP 5.5.x vyžadoval následnou změnu uživatelského hesla u uživatelů databáze - to jsem čekal a věděl, že pravděpodobně budu muset vytvořit nové uživatele ->
u MyISAM -> vše OK, změnil jsem heslo v administraci a jede se dál
u InnoDB -> změna hesla ani vytvoření úplně nového usera nepomohlo
Hláška, že musim nastavit heslo pomocí SET PASSWORD -> nemám oprávnění
-> po hodině snažení jsem byl nucen přepnout zpět na PHP 5.4
Prosím o vyřešení problému u InnoDB, případně nagrantovat dočasně práva na set password
Předem díky
Děkuji za rychlou reakci a aktivní řešení problému, snad už to bude brzy OK. Hezký den.
Ok, vyčkám. Výpadek trvá minimálně od dnešních 11 hodin, pokud Vám to nějak pomůže.
nedostanu se do administrace DB, kterou mám jako InnoDB, MyISAM jede OK.
Hláška: Nelze se připojit ke vzdálenému serveru
Nevím, jestli má cenu ještě reagovat, protože se, původně dobře myšlené, varování zvrhlo ve výsměch mému CMS, které nikdo z Vás neviděl. Praktickým penetračním testům systému Wordpress a dalších opensource CMS jsem se věnoval při psaní bakalářské práce a řešení některých objevených nedostatků postupně zakomponovávám do vlastního CMS, které je stále ve vývoji, takže tady netvrdím, že je nějak dokonalé (to už by ho dávno zpeněžil), ale taky odmítám odsuzování, že není zabezpečené, protože na jeho vývoji pracuji sám a nepoužívám dostupné CMS řešení.
Hezký zbytek dne.
(pokud by někoho zajímaly výsledky testování penetrací OS CMS verzí 2012/2013, tak mi napište seriózní kontakt)
Nn, nevyužívám žádný vytvořený systém, vyvýjím vlastní CMS, kvpodstatě nedošlo k žádným škodám, k útoku došlu v rámci skriptu, který je několik let mimo - prostě se na nej zapomělo a to byla chyba. Jen jsem chtěl varovat ostatní, protože průběh útoku se mi zdál vysoce profesionální. Rozhodně nešlo o žádné amatéry, kteří hacknout nanejvýš tak ten wordpress, což opravdu není žádný problém.
Hezký den všem příznivcům Endory,
včera mi Syrská hackerská skupina Syrian EnGel Hackers částečně nabourala stránky, využila techniky sql injection. Jejich postup byl podle mě velmi profesionální a připravený (jednotlivé sql dotazy se posílaly po 1 vteřině), po 15 minutách prolomili zabezpečení a vložili několik záznamů do databáze, kde propagovali své politické přesvědčení ohledně občanské války v Sýrii.
Hackeři pochopitelně využili slabého místa v zabezpečení - jejich sql injection dokázal obejít standardní zabezpečení vstupu pomocí funkce myslq_escape_string() a dalších běžně používaných.
Přístup byl z IP adresy lokalizované ve Spojených Arabských Emirátech - 94.59.78.208
Několik hodin předtím se o neúspěšné prolomení na stejném scriptu pokusili i z ip - 38.126.52.32
Tímto jsem jen chtěl varovat ostatní, aby si překontrolovali jak ošetřují vstupy, které poté pracují z databází - i na těch nejméně pravděpodobných a zapomenutých místech základní funce nestačí.
Zdraví kokos
Děkuji za pomoc a rychlé reakce, přeji hezký zbytek dne.
Dobře, kouknu na to, ale nepředpokládám, že je problém v odesílateli, maily přímo z <!-- e --><a href="mailto:vse-testy@seznam.cz">vse-testy@seznam.cz</a><!-- e --> odeslané Seznamem na G-mail chodí bez problémů, problém je u mailů odeslaných php. Hlavička pokusného mailu (odesláno z webu na <!-- e --><a href="mailto:vse-testy@seznam.cz">vse-testy@seznam.cz</a><!-- e -->):
Received: from srv7.endora.cz (srv71.endora.cz [88.86.120.160])
by email-smtpd-v5.ng.seznam.cz (Seznam SMTPD UNKNOWN@UNKNOWN) with ESMTP;
Mon, 20 May 2013 23:20:08 +0200 (CEST)
Received: from zakaznik by srv7.endora.cz with local (Exim 4.72)
(envelope-from <zakaznik@srv7.endora.cz>)
id 1UeXV1-00024T-MS
for vse-testy@seznam.cz; Mon, 20 May 2013 23:20:07 +0200
Date: Mon, 20 May 2013 23:20:07 +0200
Message-Id: <E1UeXV1-00024T-MS@srv7.endora.cz>
To: vse-testy@seznam.cz
Subject: test1
X-PHP-Originating-Script: 3333:mail.php
Content-type: text/html; charset=utf-8
From: Vse-Testy <vse-testy@seznam.cz>
X-Smtpd: UNKNOWN@UNKNOWN
X-Session: 60
X-Country: CZ
...telo mailu...Přidejte u g-mailu odesilatele do adresáře a mělo by být po problému.
Nejsem si jistý, zda jste pochopil můj problém, jedná se o aktivační e-maily, které posíláme uživatelům a nikdo z nich nebude mít odesílatele v adresáři. Nicméně děkuji za objasnění možné příčiny.
vse-testy.cekuj.net, odesílatel je uveden jako <!-- e --><a href="mailto:vse-testy@seznam.cz">vse-testy@seznam.cz</a><!-- e -->