Wpis z mikrobloga

@durek89

sama metoda do finisza:

private string finishUpload(string destinationUrl)
{
var finishJson = "{ \"ReferenceNumber\": \"" + transactionInfo.InitReferenceNumber + "\", \"AzureBlobNameList\": [ \"" + transactionInfo.InitBlobName + "\" ]}";

byte[] bytes;
bytes = System.Text.Encoding.ASCII.GetBytes(finishJson);

string finishResult = performRESTRequest(destinationUrl, "POST", "application/json; encoding='utf-8'", bytes);
transactionInfo.Log += finishResult;

return finishResult;
}

ta metoda performRESTRequest to mój twór - wyekstraktowałem sobie część wspólną z kilku tych restów. Nie wiem w czym dokładnie masz problem, ale to działa:
@Svenson8: na kolejne testy bez zmian w kodzie, otrzymałem status 410 :( więc powtarzalny status 302 nie mogę potwierdzić. Miejmy tylko nadzieję, że w testowej bramce będzie też dostępna funkcjonalność produkcyjnej i szybsze odpowiedzi na testy...
Ja olałem temat bo żeby wygenerować XMLa który PO spakowaniu ma 60MB to musi być naprawde opasły plik. U nas nie przewidujemy żeby nawet przed spakowaniem XMLe były większe niż kilkanaście MB. Bo mówimy tutaj tylko o JPK_VAT - pozostałe pliki są "na żądanie" w razie kontroli - a je juz się nie przesyła tylko mozna przekazać np. na pendrive z tego co wiem.
@Liferov
using (ZipFile zip = new ZipFile())
{
zip.CompressionMethod = CompressionMethod.Deflate;
zip.UseZip64WhenSaving = Zip64Option.AsNecessary;
zip.MaxOutputSegmentSize = 62914560;
zip.AddFile(Plik,"");
zip.Save(sciezka);
}
Witam, dzięki zawartym tu poradom udało mi się wygenerować, podpisać i wysłać plik z metadanymi InitUpload. Pobieram również status - wieczne "Rozpoczęto sesję przesyłania plików". Mógłby ktoś wrzucić kod do Putblob (Azure)? Z góry dzięki.
Przede wszystkim: dziękuję Wam za dzielenie się wiedzą :)

@yarpi87: widzę, ze też miałeś problem z md5 - jak sobie poradziłeś z niezgodnością md5?
@durek89: tak miałem, dostałem 410 na pre-produkcji, u Ciebie przeszło? może coś źle mam z szyfrowaniem. Poza tym zgodnie z najnowszą dokumentacją: "Wymagana metoda kompresji to format pliku ZIP z użyciem algorytmu DEFLATE, bez stosowania opcji dzielenia (split/multipart).W wyniku kompresji powinien powstać jeden plik ZIP zawierający pojedynczy dokument JPK. Jeżeli rozmiar otrzymanego pliku ZIP przekracza 60MB, należy go podzielić binarnie na odpowiednią liczbę części o wielkości 60MB każda oraz ostatnią część
Cześć,
zacznę od tego, że na przykładach ze stronki mf.gov.pl i własnych udało się zrobić aplikację .Net, która wykonuje wszystkie wymagane operacje na plikach, aż do otrzymania InitUpload.xml, który potem podpisujemy zewnętrznymi aplikacjami Szafir/proCertum i wrzucamy na Azure - w tym momencie trzy kroki wykonywane przez dwie różne apki.

Krok1: (C#): Przygotowanie plików i metadanych
Krok2: proCertum albo żenujący javovy applet Szafira: Podpisanie pliku
Krok3: (C#): Komunikacja z Azurem

(jeśli ktoś potrzebuje
@xide odłożyłem temat na dwa dni żeby podgonić zległości jutro wracam. Nie mam 100% pewności że to wina MD5, ale na pewno mi krzyczy że schemat niezgodny z XDS i wskazuje na pole Hash. Niby za długie - jutro od rana bede to badał.

@Spokey miałem dokłądnie taki sam błąd jak podpisywałem biblioteką Micosoft.Xades. Ale jak przeszedłem na XadesNet to łyknął i teraz krzyczy mi o to że hashe mi sie nie
@yarpi87 Mam identycznie tak jak Ty. Używałem gotowej biblioteki XadesNetLib.dll z XadesNetTestProjectv1.0.1NET3.5.zip. Później skompilowałem dll z XadesNet_v1.0.1-src.zip i ciągle źle podpisuje (już jest błąd XadesHelper.Verify(outputPath).Perform(); i z bramki mam kod 120 "Podpis negatywnie zweryfikowany").

Próbowałem na lipnym oraz na prawdziwym certyfikacie i nic.

Może coś z wyborem certyfikatu?:

X509Store store = new X509Store(StoreLocation.CurrentUser);
store.Open(OpenFlags.ReadOnly | OpenFlags.OpenExistingOnly);
X509Certificate2Collection certificates = store.Certificates;

X509Certificate2Collection foundCertificates = certificates;
selectedCertificates = X509Certificate2UI.SelectFromCollection(foundCertificates,
"Wybór certyfikatu", "Wybierz
Wybór mam tak samo, z tym że biore z StoreLocation.LocalMachine ale to nie powinno mieć wpływu. Ja kompilowałem sam z XadesNet_v1.0.1-src.zip . Co prawda też sam lib jak wywołam: XadesHelper.Verify(outputPath).Perform(); to mi sypie błędem że podpis nieprwidłowy, ale bramka przyjmuje (na to wyglada) - mam status 140 teraz, no chyba że te hashe to są sprawdzane PRZED sprawdzaniem podpisu. Ale raczej nie bo wcześniej miałem status 120 na tamtym libie taki jak
Czy komuś z szanownych przeszło dziś UPO? Bo mi czeka i na testowym (chyba tam to mają całkiem wyłączone) i na produkcyjnym na statusie 120 od paru godzin