1
Windows a jiné systémy / Re:Finderem se nepřipojím na smb://
« kdy: 07. 10. 2024, 18:25:36 »
Podle popisovaného projevu tipuju spíš na problém s FS na NASu. Jde se na něj v pohodě připojit z jiného zařízení?
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
Ze me nenapadlo to grepnout samotneho, kdyz ty logy mam!
Je tam taky static MAC, zaznamy DHCPDISCOVER koreluji na dny a hodiny prichodu spravne.
Jsem tedy zvedavy zda se jeji zarizeni zitra objevi pak stejne.
Nevis nahodou, jaky je default pro nove pridane pripojeni? (random, nebo static?)
The feature is called ‘Private [Wi-Fi] Address’ and a full description can be found here. It also appears that Apple will leave this feature on as default, which then of course means that MAC randomization will be activated on all iOS14 devices, unless actively disabled. The feature will make sure that MAC addresses will change every 24 hours, sources explain.https://wifinowglobal.com/news-and-blog/new-private-wi-fi-address-iphone-feature-could-severely-impact-the-wi-fi-industry-expert-says/
Ale mam tusaka, ze nejaky dobrak se to MAC based prsteni bude snazit sabotovat randomizaci - dalsi technologie co prinasi vice problemu nez uzitku.
…kdyz koupis kradeny iphone tak ho nijak neresetnes. Budes mit cihlicku ktera bude chtit prihlaseni k registrovanemu uctu…Jste si tímhle naprosto jistý? Takže všechny postupy, co na netu existují a stačí jim např. kabel, iTunes a PC/Mac (a o nutnosti použít Apple ID tam není ani tečka), tak neplatí, popř. v nich tahle zásadní informace o Apple ID chybí? Nebo mi něco uniká?
Napadlo me jeste jestli zkratka cteni tech souboru neudelat bokem, tj. mimo SOAP, a v SOAP nechat jen zbytek toho co je potreba komunikovat + vazbu na ty soubory.Rozšíření MTOM je, IMHO, atypické v tom, že po SOAP klientovi požaduje specifickou funkcionalitu - xop:Include se má chovat jako něco, co vrátí obsah MIME multipart bloku do nadřazeného uzlu - a na tom asi selhává interní soap_client php. Řešení mám zatím tato:
Pokud je to jen SOAP / REST proxy, nebylo by jednodušší ji napsat v Javě místo PHP? :-)Nebylo by to jednodussi/rychlejsi v go?
Mate namapovane typy zo soap response na php typy? (classmap v options pre konstruktor soap klienta)Jo, kolega má podobný nápad ale z "druhého konce" - úpravou definice v WSDL/XSD. Právě kvůli tomu, že existuje mapping to nemůžeme udělat jednoduše. Služba je hodně komplexní, nad jedním endpointem je nadefinovaných cca 700 datových typů (php tříd!) a právě ty, které v sobě mají odezvu z xop:Include jsou jako string a nikoliv spec. typ. Muselo by se to řešit na několika (mnoha) místech ....
Ak ano, tak pre xop:include nadefinujete triedu, ktora poskytne stream na includovany zdroj.
Btw, REST proxy na SOAP server asi moc nenajdete, struktura xml je daleko komplexnejsia ako json. Na to si budete musiet napisat vlastny kod, prisposobeny jednak WDSL toho soapu, tak aj rozhraniu toho rest serveru.
Co tenhle ?O tomto vím - bohužel připojené části budou obrovské ... mám toto jako krajní "řešení" problému. Ale je to o vlastní implementaci __doRequest a čtení vstupu jako streamu, rozhození jednotlivých částí do souborů v tempu a nahrazení xop:Include řetězcem cesty k těm souborům... Tohle je náš "krizový" scénář ale regulérní řešení s klientem, který zvládá toto rozšíření SOAP o NS xop by bylo lepší ....
https://github.com/debuss/MTOMSoapClient
Ale i tak to asi bude dost prasarna, poskládat si to pak z base64 zpět to bude trvat.
Diskuze o MTOM https://sourceforge.net/p/nusoap/discussion/193578/thread/abe3287e/Dík, o tomto vím - naše zprávy mají tendenci být obrovské (desítky až stovky MB) z tohoto důvodu musíme číst multipart jako stream a rozhazovat do souborů. Ale pokus o vlastní implementace klienta je až krajní řešení. NuSOAP je už spoustu let neudržovaná. Narazil jsem na GH na phpro implementaci klienta, která je živá a udržovaná, ale té chybí podpora pro MTOM úplně ( https://github.com/phpro/soap-client )
My NuSOAP pouzivame, ale bez MTOM.