We are configuring Spring Security Kerberos extension in OWF 7 (Ozone Widget Framework) on JBoss AS 7.1.1. We see the following error:
23:01:44,172 WARN [org.springframework.security.extensions.kerberos.web.SpnegoAuthenticationProcessingFilter] (http--10.200.69.103-8080-2) Negotiate Header was invalid: Negotiate TlRMTVNTUAABAAAAl4II4gAAAAAAAAAAAAAAAAAAAAAGAbEdAAAADw==: org.springframework.security.authentication.BadCredentialsException: Kerberos validation not succesfull
at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator.validateTicket(SunJaasKerberosTicketValidator.java:69) [spring-security-kerberos-core-1.0.0.M2.jar:]
at org.springframework.security.extensions.kerberos.KerberosServiceAuthenticationProvider.authenticate(KerberosServiceAuthenticationProvider.java:86) [spring-security-kerberos-core-1.0.0.M2.jar:]
at org.springframework.security.authentication.ProviderManager.doAuthentication(ProviderManager.java:120) [spring-security-core-3.0.2.RELEASE.jar:]
at org.springframework.security.authentication.AbstractAuthenticationManager.authenticate(AbstractAuthenticationManager.java:48) [spring-security-core-3.0.2.RELEASE.jar:]
at org.springframework.security.extensions.kerberos.web.SpnegoAuthenticationProcessingFilter.doFilter(SpnegoAuthenticationProcessingFilter.java:131) [spring-security-kerberos-core-1.0.0.M2.jar:]
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355) [spring-security-web-3.0.2.RELEASE.jar:]
at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:79) [spring-security-web-3.0.2.RELEASE.jar:]
at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:355) [spring-security-web-3.0.2.RELEASE.jar:]
at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:149) [spring-security-web-3.0.2.RELEASE.jar:]
at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237) [org.springframework.web-3.0.5.RELEASE.jar:3.0.5.RELEASE]
at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167) [org.springframework.web-3.0.5.RELEASE.jar:3.0.5.RELEASE]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.13.Final.jar:]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:153) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
Caused by: java.security.PrivilegedActionException: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0_31]
at javax.security.auth.Subject.doAs(Subject.java:396) [rt.jar:1.6.0_31]
at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator.validateTicket(SunJaasKerberosTicketValidator.java:67) [spring-security-kerberos-core-1.0.0.M2.jar:]
... 23 more
Caused by: GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
at sun.security.jgss.GSSHeader.<init>(GSSHeader.java:80) [rt.jar:1.6.0_31]
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:287) [rt.jar:1.6.0_31]
at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:267) [rt.jar:1.6.0_31]
at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator$KerberosValidateAction.run(SunJaasKerberosTicketValidator.java:146) [spring-security-kerberos-core-1.0.0.M2.jar:]
at org.springframework.security.extensions.kerberos.SunJaasKerberosTicketValidator$KerberosValidateAction.run(SunJaasKerberosTicketValidator.java:136) [spring-security-kerberos-core-1.0.0.M2.jar:]
... 26 more
I saw a post on stack overflow ("Defective token detected" error (NTLM not Kerberos) with Kerberos/Spring Security/IE/Active Directory) and thought someone can help me with our situation.
Our setup:
JDK 1.6.0_31
JBoss AS 7.1.1.Final running on Red Hat Enterprise Linux Server release 6.2 (Santiago) Kernel 2.6.32-220.el6.x86_64 on an x86_64
Windows Server 2008 Active Directory
Spring Security Kerberos Extension M2 (configured following the instructions provided in their blog: http://blog.springsource.com/2009/09/28/spring-security-kerberos/ )
Firefox 21 (runs on a VM)
IE 10 (runs on a VM)
From the previous post listed above it appears like AD server is sending an NTLM token to IE and IE is sending this to application. We have our Application Server (JBoss), AD Server and client (IE, Firefox) on different machines
joined to the same domain. Below is the krb5.conf file from /etc folder of the linux box where JBoss is:
[libdefaults]
default_realm = ENTERPRISELABS.MYCOMPANY.COM
default_tgs_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
default_tkt_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
permitted_enctypes = aes256-cts aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc
dns_lookup_realm = true
dns_lookup_kdc = true
passwd_check_s_address = false
noaddresses = true
udp_preference_limit = 1
ccache_type = 3
kdc_timesync = 0
kdc_timesync = 0
[domain_realm]
.enterpriselabs.com = ENTERPRISELABS.MYCOMPANY.COM
enterpriselabs.com = ENTERPRISELABS.MYCOMPANY.COM
.cdc.lab = ENTERPRISELABS.MYCOMPANY.COM
cdc.lab = ENTERPRISELABS.MYCOMPANY.COM
.dcas-i-2-069103 = ENTERPRISELABS.MYCOMPANY.COM
.enterpriselabs.mycompany.com = ENTERPRISELABS.MYCOMPANY.COM
dcas-i-2-069103 = ENTERPRISELABS.MYCOMPANY.COM
enterpriselabs.mycompany.com = ENTERPRISELABS.MYCOMPANY.COM
mcc-ad01.enterpriselabs.mycompany.com = ENTERPRISELABS.MYCOMPANY.COM
mcc-ad03.enterpriselabs.mycompany.com = ENTERPRISELABS.MYCOMPANY.COM
scr0-i-1-069137.scr0.enterpriselabs.mycompany.com = SCR0.ENTERPRISELABS.MYCOMPANY.COM
ssbox8.cdc.lab = ENTERPRISELABS.MYCOMPANY.COM
[realms]
ENTERPRISELABS.MYCOMPANY.COM = {
kdc = mcc-ad01.enterpriselabs.mycompany.com:88
master_kdc = mcc-ad01.enterpriselabs.mycompany.com:88
kpasswd = mcc-ad01.enterpriselabs.mycompany.com:464
kpasswd_server = mcc-ad01.enterpriselabs.mycompany.com:464
kdc = mcc-ad03.enterpriselabs.mycompany.com:88
master_kdc = mcc-ad03.enterpriselabs.mycompany.com:88
kpasswd = mcc-ad03.enterpriselabs.mycompany.com:464
kpasswd_server = mcc-ad03.enterpriselabs.mycompany.com:464
}
SCR0.ENTERPRISELABS.mycompany.COM = {
kdc = scr0-i-1-069137.scr0.enterpriselabs.mycompany.com:88
master_kdc = scr0-i-1-069137.scr0.enterpriselabs.mycompany.com:88
kpasswd = scr0-i-1-069137.scr0.enterpriselabs.mycompany.com:464
kpasswd_server = scr0-i-1-069137.scr0.enterpriselabs.mycompany.com:464
}
Under [domain_realm] block the first 2 entries won't have .mycompany in them. Is this a problem?
We generated the keytab file by running the following command:
ktpass /princ HTTP/jaguar.enterpriselabs.mycompany.com#ENTERPRISELABS.MYCOMPANY.COM /mapuser jaguar#ENTERPRISELABS.MYCOMPANY.COM -crypto all -pass password -ptype KRB5_NT_PRINCIPAL -out c:\jaguar-host.keytab
We copied the keytab file generated to the WEB-INF/classes folder of our application on JBoss. When we contacted our tech support they also mentioned that test user accounts created have 'Kerberos Authentication'
checkbox checked. I think when we login to the domain we are authenticated using kerberos not NTLM (I don't know whether it is correct or not). But, this didn't help us getting rid of the above problem.
I used fiddler and saw 'NTLM Authentication' in one of the screens. Please help us in debugging this problem. I think the problem is in AD somewhere and don't know where to look for answers. Do we have to follow any specific
steps to make sure our AD is configured right? Is there a way to configure AD server to send Kerberos token?
Are you sure that jaguar.enterpriselabs.mycompany.com is DNS A record hostname instead of CNAME alias?
I think I had a similar error message when I created the keytab using a DNS alias hostname (CNAME).
When browser asks KDC for the ticket, it always uses the DNS A record hostname, regardless of the hostname you have in browser address bar. Users can still use CNAME alias hostnames to access the site, but the keytab must be created using A record hostname.
Related
I have been learning Flask (with the help of many very generous YouTuber's)
I thought adding a 'Subscribe' function that sends an email notification via GMail would be fairly straightforward.
After a few days of Googling around I am getting the following results from each combination of port 465 or 587, SSL and/or TLS enabled/disabled.
Less secure apps option in Gmail is permitted.
from flask import Flask
from flask_mail import Mail, Message
app = Flask(__name__)
app.config['MAIL_DEBUG'] = True
app.config['TESTING'] = False
app.config['MAIL_SERVER'] = 'smtp.gmail.com'
app.config['MAIL_PORT'] = see results below
app.config['MAIL_USE_TLS'] = see results below
app.config['MAIL_USE_SSL'] = see results below
app.config['MAIL_USERNAME'] = None
app.config['MAIL_PASSWORD'] = 'secret_password'
app.config['MAIL_DEFAULT_SENDER'] = 'me#gmail.com'
app.config['MAIL_MAX_EMAILS'] = None
app.config['MAIL_SUPPRESS_SEND'] = False
app.config['MAIL_ASCII_ATTACHMENTS'] = False
mail = Mail(app)
#app.route('/')
def home():
msg = Message('Test Message from Flask Mail', recipients=['you#gmail.com'])
mail.send(msg)
return 'OK'
if __name__ == '__main__':
app.run(debug=True)
Results in -
Port SSL TLS Result
465 On On smtplib.SMTPNotSupportedError: STARTTLS extension not supported by server
465 Off On smtplib.SMTPServerDisconnected: Connection unexpectedly closed
465 On Off smtplib.SMTPSenderRefused: (530, b'5.7.0 Authentication Required
465 Off Off smtplib.SMTPServerDisconnected: Connection unexpectedly closed
587 On On ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number
587 Off On smtplib.SMTPSenderRefused: (530, b'5.7.0 Authentication Required
587 On Off ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number
587 Off Off smtplib.SMTPSenderRefused: (530, b'5.7.0 Must issue a STARTTLS command first
SSL version is -
import ssl
ssl.OPENSSL_VERSION
'OpenSSL 1.1.1f 31 Mar 2020'
This SMTPLIB works just fine -
import smtplib
smtp_server = 'smtp.gmail.com'
port = 587
sender = 'me#gmail.com'
password = 'secret'
receiver = 'you#gmail.com'
msg = "Test Message from SMTPLIB"
server = smtplib.SMTP(smtp_server, port)
server.starttls()
server.login(sender,password)
server.sendmail(sender, receiver, msg)
It's been a few years now but worked for me (looking at an old code) was
app.config['MAIL_PORT'] = 587
app.config['MAIL_USE_TLS'] = True
app.config['MAIL_USE_SSL'] = False
app.config['MAIL_USERNAME'] = <your email address> # should not be None as you currently have in your code
Note: I only used this code for testing on my local machine. I switched to Google App Engine mail and later SendGrid
We have a HDP (3.1.0) cluster with Hive (3.0.0.3.1). The cluster is Kerberised;
I am trying to connect to Hive with DBVisualizer, without success. The client (where I am using DBVisualizer from) is a Centos 7 Machine.
Kerberos related
On the client, here is the /etc/krb5.conf (copy/paste from one of the cluster's machine):
cat krb5.conf
[libdefaults]
renew_lifetime = 7d
forwardable = true
default_realm = COMPANY.LOC
ticket_lifetime = 24h
dns_lookup_realm = false
dns_lookup_kdc = false
default_ccache_name = /tmp/krb5cc_%{uid}
#default_tgs_enctypes = aes des3-cbc-sha1 rc4 des-cbc-md5
#default_tkt_enctypes = aes des3-cbc-sha1 rc4 des-cbc-md5
[domain_realm]
COMPANY.LOC = COMPANY.LOC
[logging]
default = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
kdc = FILE:/var/log/krb5kdc.log
[realms]
COMPANY.LOC = {
admin_server = server.company.loc
kdc = server.company.loc
}
I used kinit and here is the result of klist:
[florianc#localhost etc]$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: castelainf#COMPANY.LOC
Valid starting Expires Service principal
07/24/2020 09:12:03 07/24/2020 19:12:03 krbtgt/COMPANY.LOC#COMPANY.LOC
renew until 07/31/2020 09:11:59
DbVisualizer
Version: 11.0.4 (free)
Tools>Tool Properties>Specify overridden Java VM Properties here:
-Dsun.security.krb5.debug=true
-Djavax.security.auth.useSubjectCredsOnly=false
-Djava.security.krb5.conf="/etc/krb5.conf"
The JAR used for the driver is the one provided by the cluster in Ambari>Hive>JDBC Standalone jar
The database URL of the connection is:
jdbc:hive2://server1.company.loc:2181,server2.company.loc:2181,server3.company.loc:2181/;serviceDiscoveryMode=zooKeeper;zooKeeperNamespace=hiveserver2;principal=hive/_HOST#COMPANY.LOC
The error returned when trying to connect is the following:
Could not open client transport for any of the Server URI's in ZooKeeper: Can't get Kerberos realm
Edit 1
Using these URIs:
jdbc:hive2://server1.company.loc:2181/;principal=hive/_HOST#COMPANY.LO
jdbc:hive2://server1.company.loc:2181/;principal=hive/server1#COMPANY.LOC
jdbc:hive2://server1.company.loc:2181/;principal=hive/server1.company.loc#COMPANY.LOC
Always return:
Could not open client transport with JDBC Uri <URI>: Can't get Kerberos realm
I want to use couchDB(V. 2.3.1) with SSL enabled, so I added [ssl] part to /opt/couchdb/etc/local.d/docker.ini file as shown below:
[ssl]
port = 6984
enable = true
cert_file = /etc/hyperledger/fabric/tls/server.crt
key_file = /etc/hyperledger/fabric/tls/server.key
cacert_file = /etc/hyperledger/fabric/tls/ca.crt
[daemons]
httpsd = {couch_httpd, start_link, [https]}
[admins]
Admin = ...
[couchdb]
uuid = ...
but i can't access the webUI with https! having this error:
This site can’t provide a secure connection
"IP" uses an unsupported protocol.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Unsupported protocol
The client and server don't support a common SSL protocol version or cipher suite.
this is the logs:
[error] 2020-05-17T06:52:18.046389Z nonode#nohost <0.19077.3> -------- SSL: hello: tls_handshake.erl:127:Fatal error: handshake failure - malformed_handshake_data
[error] 2020-05-17T06:52:18.046426Z nonode#nohost <0.18899.3> -------- application: mochiweb, "Accept failed error", "{error,{tls_alert,\"handshake failure\"}}"
[error] 2020-05-17T06:52:18.046508Z nonode#nohost <0.18899.3> -------- CRASH REPORT Process (<0.18899.3>) with 0 neighbors exited with reason: {error,accept_failed} at mochiweb_acceptor:init/4(line:75) <= proc_lib:init_p_do_apply/3(line:247); initial_call: {mochiweb_acceptor,init,['Argument__1','Argument__2',...]}, ancestors: [https,couch_secondary_services,couch_sup,<0.202.0>], messages: [], links: [<0.253.0>], dictionary: [], trap_exit: false, status: running, heap_size: 1598, stack_size: 27, reductions: 954
can somebody please help me?
I found the solution and wrote a post about it:
https://medium.com/#pouyashojaei85/enabling-ssl-for-docker-couchdb-container-127388eca1a8
I have a deployment of RabbitMQ that uses it's own certificates for end-to-end encryption. It uses both AMQP and MQTT-over-WSS to connect multiple types of clients. AMQP clients are able to connect securely, so I know that the certificate set up is good.
Clients using WS going to ws://hostname:15675/ws can connect fine, but obviously are not secure. Clients attempting to connect to wss://hostname:15676/ws have the connection closed on them. 15676 is the port you will see I have bound the web-mqtt ssl listener to, as shown below. I've gone through both the networking and tls help guide by RabbitMQ, and I see the port correctly bound and can confirm it is exposed and available to the client.
The relevant rabbit.conf:
listeners.tcp.default = 5671
listeners.ssl.default = 5671
ssl_options.cacertfile = /path/to/fullchain.pem
ssl_options.certfile = /path/to/cert.pem
ssl_options.keyfile = /path/to/privkey.pem
ssl_options.verify = verify_none
ssl_options.fail_if_no_peer_cert = false
web_mqtt.ssl.port = 15676
web_mqtt.ssl.backlog = 1024
web_mqtt.ssl.cacertfile = /path/to/fullchain.pem
web_mqtt.ssl.certfile = /path/to/cert.pem
web_mqtt.ssl.keyfile = /path/to/privkey.pem
Basically, I'm wondering if I have the connection string wrong (wss://hostname:15675/ws)? Do I need to go to /wss? Is it a problem my client is a browser running on localhost -- not HTTPS? Do I have a configuration set incorrectly -- am I missing one?
If there is a better source of documentation/examples of this plugin beyond the RabbitMQ website, I would also be interested.
maybe the configuration mismatch
if there any password for the private file you need to add it also.
refer to the following sample rabbitmq.conf
listeners.ssl.default = 5671
ssl_options.cacertfile = <path/ca-bundle (.pem/.cabundle)>
ssl_options.certfile = <path/cert (.pem/.crt)>
ssl_options.keyfile = <path/key (.pem/.key)>
ssl_options.password = <your private key password>
ssl_options.versions.1 = tlsv1.3
ssl_options.verify = verify_peer
ssl_options.fail_if_no_peer_cert = true
ssl_options.ciphers.1 = TLS_AES_256_GCM_SHA384
ssl_options.ciphers.2 = TLS_AES_128_GCM_SHA256
ssl_options.ciphers.3 = TLS_CHACHA20_POLY1305_SHA256
ssl_options.ciphers.4 = TLS_AES_128_CCM_SHA256
ssl_options.ciphers.5 = TLS_AES_128_CCM_8_SHA256
ssl_options.honor_cipher_order = true
ssl_options.honor_ecc_order = true
web_mqtt.ssl.port = 15676
web_mqtt.ssl.backlog = 1024
web_mqtt.ssl.cacertfile = <path/ca-bundle (.pem/.cabundle)>
web_mqtt.ssl.certfile = <path/crt (.pem/.crt)>
web_mqtt.ssl.keyfile = <path/key (.pem/.key)>
web_mqtt.ssl.password = <your private key password>
web_mqtt.ssl.honor_cipher_order = true
web_mqtt.ssl.honor_ecc_order = true
web_mqtt.ssl.client_renegotiation = false
web_mqtt.ssl.secure_renegotiate = true
web_mqtt.ssl.versions.1 = tlsv1.2
web_mqtt.ssl.versions.2 = tlsv1.1
web_mqtt.ssl.ciphers.1 = ECDHE-ECDSA-AES256-GCM-SHA384
web_mqtt.ssl.ciphers.2 = ECDHE-RSA-AES256-GCM-SHA384
web_mqtt.ssl.ciphers.3 = ECDHE-ECDSA-AES256-SHA384
web_mqtt.ssl.ciphers.4 = ECDHE-RSA-AES256-SHA384
web_mqtt.ssl.ciphers.5 = ECDH-ECDSA-AES256-GCM-SHA384
web_mqtt.ssl.ciphers.6 = ECDH-RSA-AES256-GCM-SHA384
web_mqtt.ssl.ciphers.7 = ECDH-ECDSA-AES256-SHA384
web_mqtt.ssl.ciphers.8 = ECDH-RSA-AES256-SHA384
web_mqtt.ssl.ciphers.9 = DHE-RSA-AES256-GCM-SHA384
this is a working configuration file for the rabbitmq-server on ubuntu 20.04
restart the rabbitmq-server
list the listeners port (make sure that the SSL ports enabled) (rabbitmq-diagnostics listeners)
test the SSL (testssl localhost:16567)
also test the telnet (telnet localhost 16567)
please reffer : https://www.rabbitmq.com/ssl.html#erlang-otp-requirements and
troubleshooting
this is worked for me :-)
Hello I am currently using restcomm-sip-servlets-4.0.75-apache-tomcat-8.0.26. and I am having issues canceling an ongoing request from the http request thread. I noticed that this issue only appears to happen when I create a new request with an auth header like so :
AuthInfo authInfo = sipFactory.createAuthInfo();
authInfo.addAuthInfo(
response.getStatus(),
realm,myauth,password);
SipServletRequest challengeRequest = response.getSession().createRequest(
response.getRequest().getMethod());
(String)session.getAttribute("FirstPartyContent");
if(session.getAttribute("FirstPartyContent") !=null){
challengeRequest.setContent(session.getAttribute("FirstPartyContent"),(String) session.getAttribute("FirstPartyContentType"));
}
challengeRequest.addAuthHeader(response, authInfo);
challengeRequest.getFrom().setDisplayName(auth.getDisplayName());
session.removeAttribute("original");
session.setAttribute("original", challengeRequest);
challengeRequest.send();
When a request comes in via the http interface I look for the SipApplicationSession like so:
SipSessionsUtil sipSessionsUtil =
(SipSessionsUtil) session.getServletContext().
getAttribute("javax.servlet.sip.SipSessionsUtil");
logger.info("found servlet contxt for sipsession util");
SipApplicationSession tobecancelledsess = sipSessionsUtil.getApplicationSessionById(sessionapplicationID);
I then create a cancel request from the session request stored like so :
SipServletRequest req = (SipServletRequest)tobecancelledsess.getAttribute("original");
drequest = req.createCancel();
although the remote server responds a provisional with to-tag I get:
2017-04-28 16:26:04,470 DEBUG [SipServletMessageImpl] (http-bio-8443-exec-1) transaction null transactionId = null transactionType false
2017-04-28 16:26:04,470 DEBUG [SipServletMessageImpl] (http-bio-8443-exec-1) transaction null transactionId = null transactionType false
java.lang.IllegalStateException: No client transaction found! null
at org.mobicents.servlet.sip.message.SipServletRequestImpl.createCancel(SipServletRequestImpl.java:258)
at org.example.servlet.sip.CallContainer.CancelSession(CallContainer.java:319)
at org.example.servlet.sip.CallContainer.CheckCancel(CallContainer.java:274)
at org.example.servlet.sip.SimpleWebServlet.doPut(SimpleWebServlet.java:360)
at org.example.servlet.sip.SimpleWebServlet.service(SimpleWebServlet.java:149)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at org.mobicents.servlet.sip.startup.SipStandardContextValve.invoke(SipStandardContextValve.java:262)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1091)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:673)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:279)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
I noticed that when I cancel the request from the servlet class I don't have this issue.
I found that setting a context attribute at the response like this solves my issue:
if (resp.getStatus() == SipServletResponse.SC_RINGING){
SipSession session = resp.getSession();
resp.getSession().getServletContext().setAttribute("ringing",true);
}
I then grab the session context like this
SipServletRequest req = (SipServletRequest)tobecancelledsess.getAttribute("original");
Boolean ringed = (Boolean ) tobecancelledsess.getServletContext().getAttribute("ringing");
if(ringed == Boolean.True)
drequest = req.createCancel();
and eventually you need to send the cancel request with send();