Problemer med flere instanser av biblioteket deployet på samme appserver
Closed this issue · 5 comments
Hei.
Vi har deploya fleire instanser av vår avsender-applikasjon på samme tomcat-instans.
Instansene er satt opp med identisk konfigurasjon, men det vi ser er at kun siste instans som blir lasta som fungerer. (Undeployer vi instansen som virker vil instansen som feiler begynne å virke...)
Dei andre instansene feiler med følgende exception:
no.difi.sdp.webclient.service.MessageService$MessageServiceException: no.difi.sdp.client.domain.exceptions.EbmsException: EBMS:0103 - Security processing failed (actions mismatch)
Det kan se ut til at det i disse tilfellene blir generert ein mangelfull wss header.
Vi er usikre på om feilen er knytta til klient-biblioteket eller vår bruk av dette biblioteket.
Ser dere noen grunn til at denne feilen oppstår?
Her er eit eksempel på ein feilende request:
2014-12-01 14:13:28,029 http-bio-8080-exec-4 DEBUG org.apache.http.wire http-outgoing-2 >> "<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">env:Header<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" env:mustUnderstand="true"><wsu:Timestamp wsu:Id="TS-6697c783-5501-47a6-8dd2-f66f889622d9">wsu:Created2014-12-01T13:13:27.914Z/wsu:Createdwsu:Expires2014-12-01T13:18:27.914Z/wsu:Expires/wsu:Timestamp/wsse:Security<eb:Messaging xmlns:eb="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/" env:mustUnderstand="true"><ns6:UserMessage xmlns:ns10="http://uri.etsi.org/2918/v1.2.1#" xmlns:ns11="http://uri.etsi.org/01903/v1.3.2#" xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns3="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" xmlns:ns4="http://www.w3.org/2003/05/soap-envelope" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns6="http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/" xmlns:ns7="http://docs.oasis-open.org/ebxml-bp/ebbp-signals-2.0" xmlns:ns8="http://www.w3.org/1999/xlink" xmlns:ns9="http://begrep.difi.no/sdp/schema_v10" mpc="urn:normal:22fb6943-7e3e-4ecf-b29c-61ecab18e3c0">ns6:MessageInfons6:Timestamp2014-12-01T14:13:27.878+01:00/ns6:Timestampns6:MessageId3cd30c36-4f55-4bd5-940b-2cd6a6754219/ns6:MessageId/ns6:MessageInfons6:PartyInfons6:From<ns6:PartyId type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:9908">9908:991825827/ns6:PartyIdns6:Roleurn:sdp:avsender/ns6:Role/ns6:Fromns6:To<ns6:PartyId type="urn:oasis:names:tc:ebcore:partyid-type:iso6523:9908">9908:984661185/ns6:PartyIdns6:Roleurn:sdp:meldingsformidler/ns6:Role/ns6:To/ns6:PartyInfons6:CollaborationInfons6:AgreementRefhttp://begrep.difi.no/SikkerDigitalPost/1.0/transportlag/Meldingsutveksling/FormidleDigitalPostForsendelse/ns6:AgreementRefns6:ServiceSDP/ns6:Servicens6:ActionFormidleDigitalPost/ns6:Actionns6:ConversationIda8e5566e-50ca-4f8e-b261-f23cafb93c82/ns6:ConversationId/ns6:CollaborationInfons6:PayloadInfons6:PartInfo/<ns6:PartInfo href="cid:ede073cd-e21d-4e0d-9488-452437ee19d8@meldingsformidler.sdp.difi.no">ns6:PartProperties<ns6:Property name="MimeType">application/cms/ns6:Property<ns6:Property name="Content">sdp:Dokumentpakke/ns6:Property/ns6:PartProperties/ns6:PartInfo/ns6:PayloadInfo/ns6:UserMessage/eb:Messaging/env:Header<env:Body xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="soapBody"><ns3:StandardBusinessDocument xmlns:ns3="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" xmlns:ns5="http://www.w3.org/2000/09/xmldsig#" xmlns:ns9="http://begrep.difi.no/sdp/schema_v10">ns3:StandardBusinessDocumentHeaderns3:HeaderVersion1.0/ns3:HeaderVersionns3:Sender<ns3:Identifier Authority="urn:oasis:names:tc:ebcore:partyid-type:iso6523:9908">9908:991825827/ns3:Identifier/ns3:Senderns3:Receiver<ns3:Identifier Authority="urn:oasis:names:tc:ebcore:partyid-type:iso6523:9908">9908:984661185/ns3:Identifier/ns3:Receiverns3:DocumentIdentificationns3:Standardurn:no:difi:sdp:1.0/ns3:Standardns3:TypeVersion1.0/ns3:TypeVersionns3:InstanceIdentifiera8e5566e-50ca-4f8e-b261-f23cafb93c82/ns3:InstanceIdentifierns3:TypedigitalPost/ns3:Typens3:CreationDateAndTime2014-12-01T14:13:27.568+01:00/ns3:CreationDateAndTime/ns3:DocumentIdentificationns3:BusinessScopens3:Scopens3:TypeConversationId/ns3:Typens3:InstanceIdentifier46c28bb1-2e95-4884-b3ef-1f59892cb73b/ns3:InstanceIdentifierns3:Identifierurn:no:difi:sdp:1.0/ns3:Identifier/ns3:Scope/ns3:BusinessScope/ns3:StandardBusinessDocumentHeaderns9:digitalPostSaTD4/J/iL9T6vIQ5xhdxb8K4LQQPe3a2+2YCdiQxWY=Jma4WccTUWSo3RN+Hi3yCNi5Fxx/E2r2t/RhUBkBeUC6JdDrRducRhdtBEVc261qyByGqWN1acFCW3YR/7qfdHtZg/9vlr3DsGxRha3Nu+tzoWb5LagH6XbTlgQYDx1OcAHHfe8rog8BkG7DKfcPmcO+/jWHHqh2Rzk5Ov/5p1wWjw2cuU/MUF+5Ljd5xutT70x4VwunocA/ej10+kx6hKrUMFJ52/ZVITXogcyS59b7YjQmRz5AGv1VrnVUeYyWEd+xuHJWrF9err7EmkT1Qy+h25vLofd4LnHJhGa3yQxY32VVzsRQ4lLQJTB8BXUNiALzndH+LAkSWF/XhpjjyQ==MIIFOjCCBCKgAwIBAgIKGQqI22LuZ+0U6TANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJOTzEdMBsGA1UECgwUQnV5cGFzcyBBUy05ODMxNjMzMjcxIzAhBgNVBAMMGkJ1eXBhc3MgQ2xhc3MgMyBUZXN0NCBDQSAzMB4XDTE0MDYxNjA4NTYyNloXDTE3MDYxNjIxNTkwMFowgaAxCzAJBgNVBAYTAk5PMSwwKgYDVQQKDCNESVJFS1RPUkFURVQgRk9SIEZPUlZBTFROSU5HIE9HIElLVDEhMB8GA1UECwwYU0RQIC0gbWVsZGluZ3N1dHZla3NsaW5nMSwwKgYDVQQDDCNESVJFS1RPUkFURVQgRk9SIEZPUlZBTFROSU5HIE9HIElLVDESMBAGA1UEBRMJOTkxODI1ODI3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx6IPA2KSAkSupen5fFM1LEnW6CRqSK20wjpBnXf414W03eWUvBlw97c6k5sl2tYdn4aVb6Z9GeDaz1bLKN3XwhFGPk9PnjSIhrFJNAPnWVEBDqGqfeMrEsYdOEgM2veBZDYkhVwipjr8AesmptTRAat61q+6hCJe8UZqjXb4Mg6YKSTAHfJdthAG06weBMgVouQkTkeIIawM+QPcKQ3Wao0gIZi17V0+8xzgDu1PXr90eJ/Xjsw9t0C8Ey/3N7n3j3hplsZkjOJMBNHzbeBG/doroC6uzVURiuEn9Bc9Nk224b+7lOBZ1FvNNrJVUu5Ty3xyMDseCV7z1QTwW7wcpwIDAQABo4IBwjCCAb4wCQYDVR0TBAIwADAfBgNVHSMEGDAWgBQ/rvV4C5KjcCA1X1r69ySgUgHwQTAdBgNVHQ4EFgQU6JguiqDjkgjEGRHhzkbeKeqyWQEwDgYDVR0PAQH/BAQDAgSwMBYGA1UdIAQPMA0wCwYJYIRCARoBAAMCMIG7BgNVHR8EgbMwgbAwN6A1oDOGMWh0dHA6Ly9jcmwudGVzdDQuYnV5cGFzcy5uby9jcmwvQlBDbGFzczNUNENBMy5jcmwwdaBzoHGGb2xkYXA6Ly9sZGFwLnRlc3Q0LmJ1eXBhc3Mubm8vZGM9QnV5cGFzcyxkYz1OTyxDTj1CdXlwYXNzJTIwQ2xhc3MlMjAzJTIwVGVzdDQlMjBDQSUyMDM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdDCBigYIKwYBBQUHAQEEfjB8MDsGCCsGAQUFBzABhi9odHRwOi8vb2NzcC50ZXN0NC5idXlwYXNzLm5vL29jc3AvQlBDbGFzczNUNENBMzA9BggrBgEFBQcwAoYxaHR0cDovL2NydC50ZXN0NC5idXlwYXNzLm5vL2NydC9CUENsYXNzM1Q0Q0EzLmNlcjANBgkqhkiG9w0BAQsFAAOCAQEAKOTM1zSdGHWUBKPzDPYCcci9cpbktd2WuBg028bRC0NwKSWUKeuUfWesTiu/P4UlYGe86qd/+z3MNpN89aGA8pr0E0WpI+NM+v+Cb0dQwxHASHtrkVo9CVx6V6/QSBqIUEMfNquDHzxB2/mXbv6GuO5eIl3OSVKg7Ffd/1wdE6zeMmHQO+zRpfj+OVEhNPb5cLa13Ah9+JrMkr1O7VUFbozLQgFPhuI8/5+u8U/6cDOOmcFV4f4IYUmhbcLiW5MQnvaJ8044+uInOQTNtSkKmZAo7Jnm4KUyhFXftJOStOHSlODOQcepVS7csszO5yWQRMTV8doEsaH5p/LBXYF56Q==ns9:avsender<ns9:organisasjon authority="iso6523-actorid-upis">9908:991825827/ns9:organisasjon/ns9:avsenderns9:mottakerns9:personns9:personidentifikator05111600491/ns9:personidentifikatorns9:postkasseadressetest.testesen#0FSW/ns9:postkasseadresse/ns9:person/ns9:mottakerns9:digitalPostInfons9:aapningskvitteringfalse/ns9:aapningskvitteringns9:sikkerhetsnivaa3/ns9:sikkerhetsnivaa<ns9:ikkeSensitivTittel lang="NO">test - abr/ns9:ikkeSensitivTittelns9:varsler//ns9:digitalPostInfons9:dokumentpakkefingeravtrykk<ns5:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>ns5:DigestValuep1zRWrjaV1x1shTuuKWb6Qlef6RWNARuXBCjN5dB5cA=/ns5:DigestValue/ns9:dokumentpakkefingeravtrykk/ns9:digitalPost/ns3:StandardBusinessDocument/env:Body/env:Envelope[\r][\n]"
Kan du legge dette inn som xml i stedet for tekst? Kan du gi et eksempel på en request som er ok også?
Er det noen spesiell grunn til at dere deployer samme app flere ganger - det vil da bare kreve flere ressurser på deres side?
vi har laget denne: https://github.com/difi/sdp-klient-eksempel-java-webclient og publiserte den tidligere her: http://avsender-sdp.difi.no/
Denne integrerte kun mot et miljø for kontakt og reservasjonsregisteret.
Nå har vi behov for å kunne slå opp i fler forskjellige KRR miljøer avhengig av hvilket postkassemiljø vi skal teste mot.
Postkasseleverandørene har flere forskjellige testmiljø konfigurert inn mot hvert sitt KRR miljø.
Vi kunne selvsagt skrevet om vår klient slik at vi valgte hvilket kontaktregister det skal slåes opp i, men vi tenkte at det var lettere å bare deploye forskjellige varianter av applikasjonen.
Så det er vel ikke et problem som er spesielt viktig, vi har mulighet for å vurdere andre alternative deploymenter.
Så vidt jeg kan se forsvinner hele WS-Security-headeren med unntak av timestamp. Usikker hva som forårsaker dette når dere deployer flere versjoner.
Hvordan har dere satt opp classloading i tomcat? Bruker dere noen form for
shared libraries? Bruker dere saaj som følger med jdk-en eller shipper dere
deres egen variant?
- desember 2014 kl. 17.52 skrev Erlend Oftedal notifications@github.com:
Så vidt jeg kan se forsvinner hele WS-Security-headeren med unntak av
timestamp. Usikker hva som forårsaker dette når dere deployer flere
versjoner.—
Reply to this email directly or view it on GitHub
#22 (comment)
.
BEKK Open
http://open.bekk.no
TesTcl - a unit test framework for iRules
http://testcl.com
Hei igjen
Vi har ikke gjort noe spesielt ift. classloading. Bruker heller ikke noen shared libraries, eller egen saaj implementasjon. (jdk er OpenJDK Runtime Environment (IcedTea 2.5.3) (7u71-2.5.3-0ubuntu0.12.04.1))
MEN vi har gjort om på våre testmiljøer slik at vi nå kjører flere tomcat-instanser og unngår problemet. Dere behøver derfor ikke bruke noe mer tid på denne feilen, men heller ha den i bakhodet som et kjent issue dersom noen fremtidige avsendere får lignende problemer...