jeśli ktoś jest jeszcze zainteresowany to wczoraj przyczaiłem że pojawiły się noty w PLN. Na razie jest tego co kot na płakał ale w końcu coś ruszyło.

faktycznie szybko znika, no i rzadko się jeszcze pokazują

tydzień temu metoda InitUpload zwracała mi sześć nagłówków, a w chwili obecnej tylko dwa (Content-MD5 oraz x-ms-blob-type). Też tak macie? W jaki sposób teraz pozyskać Signature potrzebny do nagłówka Authorization, jak i całą resztę??

@Liferov: patrze na zwrócony adres i faktycznie :O ale co jest co? "sv" domyślam się, że to będzie x-ms-version, "sr" to nie mam pojęcia co to jest bo tam mam wartość 'b', a "si" oraz "sig" to pewnie AccountName oraz Signature, ale mogę się mylić

udało mi się połączyć z chmurą, ale dostaje odpowiedź "One of the request inputs is out of range." Ktoś ma jakiś pomysł co może być nie tak?

Podczas łączenia się z Azure dostaję informacje o tym że suma MD5 się nie zgadza. Nie wiem gdzie popełniam błąd. Z czego ta suma ma w końcu zostać wyliczana? Ze skompresowanego zaszyfrowanego pliku ZIP?

@bronek85: dzieki. Tak własnie robię, ale może faktycznie inaczej kompresuje niż powinienem. Spróbuje tak jak mówisz.

@bronek85: w jaki sposób wysyłasz tego zipa? W postaci tablicy bajtów?

@IlIlIlllIIl: co miałeś na myśli mówiąc ścieżka certyfikacji. Podzieliłem certyfikat na 3 osobne i dalej mam błąd "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."

@keytax: Mam tę samą wersję.
Format podpisu: XAdES
Typ podpisu: podpis wewnętrzny
Wariant podpisu: Nie dołączaj dodatkowych informacji (BES)
Zaawansowane opcje podpisu XAdES: Twórz podpis dołączony (Enveloped), gdy podpisywany jest dokument XML podpisem wewnętrznym XAdES
Powinno przejść a jak nie, to musisz źle wczytywać plik.

@Svenson8: nie tworzysz authorization header'a. Init upload zwraca Ci dwa headery które wysyłasz na adres który również zwraca.

Zwróciła komuś metoda Status 200? Mi dla wszystkich wysłanych plików zawsze zwraca 120, czekam już nawet kilka dni i dalej wszędzie 120stki.

Nieee. Nie potrzebujesz authorization header'a. Po init upload odbierasz adres URL który ma w adresie parametry które zastępują authorization header. Na ten adres wysyłasz skompresowany zaszyfrowany plik z dwoma headerami które otrzymujesz też z init upload i to tyle

@Svenson8: Dzięki. Nie wchodziłem ostatnio tam i nie zauważyłem tego.

ja miałem to samo, ale później maila pisałem i gdzieś wynalazłem że zmienili model na SAS i gdzieś o tym poczytałem i jakoś do tego doszedłem ;)

@Przemek78: Hah mam to samo. Coś ktoś wie co może być problemem?

mi to dalej nie działa. Wysyłacie ten plik z jakim rozszerzeniem? Zip czy aes tak jak w przykładzie z MF?

Dalej macie 120 na serwerze produkcyjnym?

@mmm234: używam tu restsharpa ale może to Ci się do czegoś przyda
public InitUploadObject InitUploadSigned(XmlDocument xml)
{
string url = "https://e-dokumenty.mf.gov.pl/api/Storage/InitUploadSigned";
var client =Pokaż całość

@mmm234: zapodaj pełną treść błędu

cały czas otrzymuje komunikat {"Code":410,"Description":"Przesłane pliki nie są prawidłowym archiwum ZIP.","Details":"ERROR_DECOMPRESS","Upo":"","Timestamp":"2016-07-27T14:46:42+00:00"} ktoś wie o co chodzi? Próbowałem różnych metod kompresji, obecnie używam tej co tutaj ktoś polecił, nie mam już pomysłu o co chodzi...

Właśnie zrobiłem tak:
Wziąłem ich initupload podpisałem go, wysłałem ich .aes i mam 200. Więc są 2 opcje: albo źle szyfruje klucz AES albo źle tym AESem szyfruje plik

może mi ktoś powiedzieć jak ładujecie ten klucz publiczny z pliku .pem? bo może tutaj jednak popełniam błąd

@mmm234: no to mam podobnie, a ustawiasz rozmiar klucza na 256? jak go pozniej importujesz do rsa?

@mmm234: chyba mam tak samo, tylko pytanie: po co kodujesz byte[] do utf8 jak później z powrotem to konwertujesz do byte[]??

taaa, w takim razie pewnie źle szyfruje tego zipa

ja mam od razu 120

{"Code":401,"Description":"Weryfikacja negatywna – dokument niezgodny ze schematem xsd","Details":"ERROR_VALIDATE","Upo":"","Timestamp":"2016-07-28T10:57:20+00:00"}

Poszlo do przodu haha

@mmm234: mi to działa już, wysłałem plik JPK z przykładu MF i dostałem 200

Ja miałem ten sam problem jak ładowałem jako xml, wyskakiwało mi coś w stylu że plik został zmodyfikowany. Spróbuj wczytać go File.ReadAllText

a jaka jest treść błedu? dla xmla i dla text

ale tam powinna być jeszcze jakaś dodatkowa informacja

odpowiedź serwera, to co dostajesz to status code i jego opis a dodatkowo serwer daje odpowiedź z opisem błedu

klucz ma na pewno 256bity (32byte)??

Ja mam tak, bo troche to przerobiłem:
konstruktor:
aes = new RijndaelManaged();

aes.KeySize = 256; //32 bytes
aes.GenerateIV();Pokaż całość

@rollon: ja wysyłałem JPK-VAT-TEST-0000.xml a initupload robiłem sam

@aksapon2: "Środowisko testowe tymczasowo będzie służyło tylko do testowania komunikacji z chmurą publiczną i status przetwarzania dokumentu będzie kończył się na kodzie 120 "Sesja została poprawnie zakończona. Dane zostały poprawnie zapisane. Trwa weryfikacja dokumentu.". Po zakończeniu prac Ministerstwo Finansów opublikuje informację o jego dostępności w pełnym zakresie przetwarzania."

@xide:
1. MD5 wysyłanego pliku na Azure
2. Mi działa normlanie po Http a robię tak jak pisałem zaszyfrowanego zipa
public string GetHashFromByte(byte[] byteArray)
{
using (MD5 md5HashPokaż całość

@yarpi87: Dobre pytanie. Znając MF to trzeba się spytać czy w ogóle ruszy w pełnym zakresie :P

@yarpi87: dokładnie tak jak mówisz. Niby są telefony i maile. Pisałem parę razy kiedyś na maila to raz odpisują raz nie, raz przekazują sprawy do kogoś i każą się z kimś tam kontaktować. Raz też dzwoniłem, ale w sumie pani która odbierała nic nie ogarniała więc sobie odpuściłem. Najlepiej chyba pisać na jpk.support@billennium.pl

już działa

też wam wisi metoda Status?

podobno Comarch ale nie jestem w 100% pewny

otrzymał ktoś coś więcej niż 303?

@aksapon2: masz moje: https://e-dokumenty.mf.gov.pl/api/Storage/Status/5ab4559b008b8a38000000b037d39541, na teście nie przechodzi więcej niż 120

@Spokey: ja miałem to samo, okazało się że źle szyfrowałem AESem, ale błąd też może być w źle zaszyfrowanym kluczu AES metodą RSA

Robiłem to różnymi sposobami aż w końcu mi to zadziałało.
Aes: http://pastebin.com/DLaR8SbG
w rsa widzę dałeś true, ja mam false:
http://pastebin.com/vpjB0xEc

Na bank musi być false dla PKCS#1

@Spokey: Daj spokój ;) ja i tak ze śląska. Daj znać czy już działa

@rollon: wszystko git, miałem to samo. Wyślij poprawny plik JPK to dostaniesz 200

@hipek1001: tak, masz tu jak to wygląda: https://e-dokumenty.mf.gov.pl/api/Storage/Status/693c90500020c2bc000000b0026546ed

@hipek1001: konwertuje do base64
@rollon: http://www.speedyshare.com/WPHCt/FA-FA2016-07-28-21-00-15.xml

@robert111222333: strasznie długo trzeba czekać, pare godzin gdzies ale nie wiem ile dokładnie bo nie odświeżam co chwilę

@durek89: nie głupie, sam to rozkminiałem ale rozszerzenie chyba nie ma znaczenia. Ja robie wszystko w pamięci także nie mam żadnego rozszerzenia. Począwszy od utworzenia zipa poprzez zaszyfrowanie i wysyłke, nic nie zapisuje na dysku

@hipek1001: VAT: https://e-dokumenty.mf.gov.pl/api/Storage/Status/693b7f7c0187bc5d000000b06f61450d

@spider07: http://pastebin.com/wXRyzAGN
@rollon: haha znam to uczucie ;)

Wątpię bo też wcześniej zapisywałem na dysku. Tak, używam tego klucza

@durek89: Nic więcej nie ustawiam niż to co jest w kodzie powyżej.
X509Certificate2 certificate = new X509Certificate2(sieżkaDoPem);
a później:
using (var rsa = (RSACryptoServiceProvider)certificate.PublicKey.Key)

@hipek1001: Ja cały czas używam 3af5843ae11db6d94edf0ea502b5cd1a.pem i mi działa

parę godzin... ale w trakcie oczekiwania dość szybko zmienia się status ze 120 do 302

@durek89:
RijndaelManaged aes;
Następnie w konstruktorze mam:
aes = new RijndaelManaged();
aes.KeySize = 256; //32 bytes
aes.GenerateIV();
aes.GenerateKey();

@durek89: z tymi opcjami co masz, też mi chyba działało. Zrezygnowałem bo mi to nie działało a później wynalazłem jakieś dwa przykłady z których zrobiłem to co udostępniłem i zadziałało więc tak już zostawiłem

@spider07: od razu w oczy mi się rzuca że szyfrujesz klucz w base64, nie wiem czy to ma znaczenie ale ja najpierw szyfruje klucz a potem konwertuje do base64

@kemot13: no tak mi się właśnie wydawało ale nie miałem 100% pewności

@rollon: puściłem ten plik przez mój validator i nie przechodzi:

"Element 'http://crd.gov.pl/xml/schematy/dziedzinowe/mf/2016/01/25/eD/DefinicjeTypy/:REGON' jest nieprawidłowy. Wartość '23456789' jest nieprawidłowa przy uwzględnieniu jego typu danych 'http://crd.gov.pl/xml/schematy/dziedzinowe/mf/2016/01/25/eD/DefinicjeTypy/:TNrREGON' - Wartość '23456789' nie jest prawidłowa dla żadnego z typów memberTypes złożeń.."

@durek89: To nie ma znaczenia, ja wcześniej zapisywałem do pliku ale to przerobiłem żeby nic nie zapisywać na dysku

@twister_ak: miałem to samo jak podupczyłem adresy. Wysyłałem na testowy a sprawdzałem na produkcyjnym
@durek89: o której metodzie mówisz? Szyfrowaniu AES czy RSA?

@kemot13: troszkę się naczekasz...

@kemot13: hehe miałem tak samo, ale dziwne bo mi po jakimś niezbyt długim czasie wskakiwał status na trzysta coś przeważnie to było 302, a dopiero później po paru godzinach na 200

a teście wciąż dostaję 120

@Gritrax: "Środowisko testowe tymczasowo będzie służyło tylko do testowania komunikacji z chmurą publiczną i status przetwarzania dokumentu będzie kończył się na kodzie 120 "Sesja została poprawnie zakończona." więc nic dziwnego

Próbował ktoś drukować UPO? Istnieje jakaś sensowna forma? Zaznajamiał ktoś się z tym tematem? Bo nie mam pojęcia jak się za to zabrać...

@mmm234: Skonfigurowałeś poprawnie SmartSign?

spoko spoko ;)

@waf6505: Dzięki wielkie!

@adam-bubula: jak miałem 303 to po paru godzinach weszło 200