We Keep Coding

Access denied error while sending proposal to peer from java sdk

I am trying to query the blockchain using the following code and getting the access denied error. also i am getting the same error while sendTransactionProposal method as well.
UserContext adminUserContext = RegisterEnrollUser.registerAdminUser(Config.CA_ORG1_URL, Config.ORG1_MSP, Config.ORG1);
FabricClient fabClient = new FabricClient(adminUserContext);
ChannelClient channelClient = fabClient.createChannelClient(Config.CHANNEL_NAME);
Channel channel = channelClient.getChannel();
Peer peer = fabClient.getInstance().newPeer(Config.ORG1_PEER_0, Config.ORG1_PEER_0_URL);
EventHub eventHub = fabClient.getInstance().newEventHub("eventhub01", Config.ORG1_PEER_0_URL_Eventhub);
Orderer orderer = fabClient.getInstance().newOrderer(Config.ORDERER_NAME, Config.ORDERER_URL);
channel.addPeer(peer);
channel.addEventHub(eventHub);
channel.addOrderer(orderer);
channel.initialize();
Collection<ProposalResponse> responsesQuery = channelClient.queryByChainCode("tmz", "queryAllEntries", null);
Caused by: org.hyperledger.fabric.sdk.exception.ProposalException: getConfigBlock for channel mychannel failed with peer peer0.org1.example.com. Status FAILURE, details: Sending proposal to peer0.org1.example.com failed because of: gRPC failure=Status{code=UNKNOWN, description=access denied: channel [mychannel] creator org [Org1MSP], cause=null}
Following are logs for peer0.org1.example.com
Principal deserialization failure (the supplied identity is not valid: x509: certificate signed by unknown authority) for identity.
WARN 2a11 [channel: mychannel] Client authorization revoked for deliver request from
Failed evaluating policy on signed data during check policy on channel [mychannel] with policy [/Channel/Application/Readers]: [Failed to reach implicit threshold of 1 sub-policies, required 1 remaining]
2018-06-14 21:05:11.545 UTC [common/deliver] Handle -> DEBU 2a12 Waiting for new SeekInfo from
2018-06-14 21:05:11.545 UTC [common/deliver] Handle -> DEBU 2a13 Attempting to read seek info message from
2018-06-14 21:05:11.609 UTC [common/deliver] Handle -> WARN 2a14 Error reading from : rpc error: code = Canceled desc = context canceled
2018-06-14 21:05:11.609 UTC [common/deliverevents] func1 -> DEBU 2a15 Closing Deliver stream

Unable to authenticate with apache http client 4.5 using kerberos ticket cache

I am executing an https request to a kerberos authenticated REST service. All is fine if I am using the keytab. However, I have a requirement that I should use the kerberos ticket cache file which is created when one logs in in the workstation using its password.
I'll replace the domain with MY_DOMAINE.COM
So, klist shows:
Ticket cache: FILE:/tmp/krb5cc_210007
Default principal: dragomira#MY_DOMAINE.COM
Valid starting Expires Service principal
05/15/18 07:21:51 05/15/18 17:21:51 krbtgt/MY_DOMAINE.COM#MY_DOMAINE.COM
renew until 05/22/18 06:18:22
Using curl like this works ok:
curl -k --negotiate -u : 'my_url' -v
Now, let's ho back to code. My login.conf is like this:
com.sun.security.jgss.login {
com.sun.security.auth.module.Krb5LoginModule required
client=TRUE
doNotPrompt=true
useTicketCache=true;
};
com.sun.security.jgss.initiate {
com.sun.security.auth.module.Krb5LoginModule required
client=TRUE
doNotPrompt=true
useTicketCache=true;
};
com.sun.security.jgss.accept {
com.sun.security.auth.module.Krb5LoginModule required
client=TRUE
doNotPrompt=true
useTicketCache=true;
};
The relevant java code for my http client which is et up for kerberos is:
try {
SSLContext sslContext = new SSLContextBuilder().loadTrustMaterial(null, (chain, authType) -> true).build();
HostnameVerifier hostnameVerifier = new NoopHostnameVerifier();
Registry<AuthSchemeProvider> authSchemeRegistry = RegistryBuilder.<AuthSchemeProvider>create()
.register(AuthSchemes.SPNEGO, new SPNegoSchemeFactory())
.build();
Credentials dummyCredentials = new NullCredentials();
CredentialsProvider credProv = new BasicCredentialsProvider();
credProv.setCredentials(new AuthScope(null, -1, null), dummyCredentials);
this.httpClient = HttpClientBuilder.create()
.setDefaultAuthSchemeRegistry(authSchemeRegistry)
.setDefaultCredentialsProvider(credProv)
.setSSLContext(sslContext)
.setSSLHostnameVerifier(hostnameVerifier)
.build();
} catch (NoSuchAlgorithmException | KeyStoreException | KeyManagementException e) {
throw new RuntimeException(e.getMessage(), e);
}
Before this, I am setting these java proerties:
java.security.auth.login.config=/home/dragomira/kerberos/login.conf
java.security.krb5.conf=/etc/krb5.conf
sun.security.krb5.debug=true
javax.security.auth.useSubjectCredsOnly=false
The output of the kerberos log is:
Loaded from Java config
>>>KinitOptions cache name is /tmp/krb5cc_210007
>>>DEBUG <CCacheInputStream> client principal is dragomira#MY_DOMANIN.COM
>>>DEBUG <CCacheInputStream> server principal is krbtgt/MY_DOMANIN.COM#MY_DOMANIN.COM
>>>DEBUG <CCacheInputStream> key type: 18
>>>DEBUG <CCacheInputStream> auth time: Tue May 15 06:18:22 EDT 2018
>>>DEBUG <CCacheInputStream> start time: Tue May 15 07:21:51 EDT 2018
>>>DEBUG <CCacheInputStream> end time: Tue May 15 17:21:51 EDT 2018
>>>DEBUG <CCacheInputStream> renew_till time: Tue May 22 06:18:22 EDT 2018
>>> CCacheInputStream: readFlags() FORWARDABLE; RENEWABLE; INITIAL; PRE_AUTH;
>>>DEBUG <CCacheInputStream> client principal is dragomira#MY_DOMANIN.COM
>>>DEBUG <CCacheInputStream> server principal is HTTP/configuration.prd.int.MY_DOMANIN.COM#MY_DOMANIN.COM
>>>DEBUG <CCacheInputStream> key type: 23
>>>DEBUG <CCacheInputStream> auth time: Tue May 15 06:18:22 EDT 2018
>>>DEBUG <CCacheInputStream> start time: Tue May 15 07:57:49 EDT 2018
>>>DEBUG <CCacheInputStream> end time: Tue May 15 17:21:51 EDT 2018
>>>DEBUG <CCacheInputStream> renew_till time: Tue May 22 06:18:22 EDT 2018
>>> CCacheInputStream: readFlags() FORWARDABLE; RENEWABLE; PRE_AUTH;
>>> unsupported key type found the default TGT: 18
So it would seem to me that the ticket is read but no credentials are extracted from it since i receive in the end 401.
Must I do something special to apache http client 4.5 in order to use ticket tacke?
Kind regards

Based on the error:
unsupported key type found the default TGT: 18
Type 18 = aes-256-cts-hmac-sha1-96 (See IANA Kerberos Parameters)
I think you are using a JRE with limited strength JCE policy and have to set unlimited strength JCE policy.
On the Oracle downloads site for Oracle JRE. Check under Additional Resources the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for JDK/JRE 8
Oracle Java SE downloads
See also: Oracle Java SE 8 technotes jgss
NOTE: The JCE framework within JDK includes an ability to enforce restrictions regarding the cryptographic algorithms and maximum cryptographic strengths available to applications. Such restrictions are specified in "jurisdiction policy files." The jurisdiction policy files bundled in Java SE limit the maximum key length. Hence, to use the AES256 encryption type, you will need to install the JCE crypto policy with the unlimited version to allow AES with 256-bit key.
Testing your policy (source):
jrunscript -e 'print (javax.crypto.Cipher.getMaxAllowedKeyLength("AES") >= 256);'
As of the start of 2018, Oracle JDK in all supported versions is beginning to ship with default unlimited strength JCE policy:
https://bugs.openjdk.java.net/browse/JDK-8189377
Also see these interesting workarounds with reflection, and a possible override setting for JRE9:
https://stackoverflow.com/a/22492582/2824577

mmm...
Default principal: dragomira#MY_DOMAINE.COM
DEBUG client principal is dragomira#MY_DOMANIN.COM
DOMANIN?

I am doing same thing in spring boot application. I am able to make rest call using cache ticket (users/conf/krb5_xyz) and authenticated properly.
my working client :
public class Test {
public static void main(String[] args) {
Map<String, Object> loginOption = new HashMap<>();
loginOption.put("refreshKrb5Config","true");
loginOption.put("useTicketCache", "true");
loginOption.put("ticketCache","h:/config/krb5cc_xyz");
loginOption.put("doNotPrompt","true");
loginOption.put("debug","true");
/*
option 1 : using keytab
KerberosRestTemplate restTemplate = new KerberosRestTemplate("C:\\Users\\xyz\\kerberos\\kerberos\\src\\main\\resources\\xyz.keytab", "wdd#sd.sd.sd");*/
/* option 2: using cache */
KerberosRestTemplate restTemplate = new KerberosRestTemplate(null , "-",loginOption);
String response = restTemplate.getForObject("http://host:13080/xyz",String.class);
System.out.println("Result"+response);
}

How to log "220 server ready" message after connecting with Apache FTPSClient

I'm writing a simple FTPS client using Apache Commons Net. Everything works fine, but the initial "server ready" message isn't being logged. I call connect() and do a getReplyString() immediately afterward, and all it logs is 234 Enabling TLS, awaiting negotiations even though I know the server is sending a message after it connects:
220 FTPS (Version Fri Jan 22 19:49:50 2016) server ready.
I've even used getReplyStrings() to see if there are more than one message, but it still only shows the one 234 Enabling TLS, awaiting negotiations message. I have a feeling it's because that's the only reply to the AUTH TLS command that gets automatically issued when I connect (explicit TLS).
I made a hack that scrapes the ProtocolCommandListener output and grabs the message that way, but I'd rather do it correctly. I have a feeling I'm missing something simple. Can anyone help?
Code:
FTPSClient ftpsclient = new FTPSClient("TLSv1.2");
// my hacked attempt to get the message
ByteArrayOutputStream baos = new ByteArrayOutputStream();
PrintStream ps = new PrintStream(baos,true,"utf-8");
ftpsclient.addProtocolCommandListener(new PrintCommandListener(ps, true));
logMessage("Connecting to FTP-SSL server [" + HOST + "] on port [" + PORT + "]...", 1);
ftpsclient.connect(HOST, PORT);
_logger.debug("Output: "+ baos.toString());
if (!FTPReply.isPositiveCompletion(ftpsclient.getReplyCode())) {
throw new Exception("Failed to connect to [" + HOST + "]\n" + ftpsclient.getReplyString());
}
logMessage(ftpsclient.getReplyString(), 1);
Output:
[Jan 22, 16:49:50] INFO logMessage() - Connecting to FTP-SSL server [HOST] on port [PORT]...
[Jan 22, 16:49:55] DEBUG - Output: 220 FTPS (Version Fri Jan 22 19:49:50 2016) server ready.
AUTH TLS
234 Enabling TLS, awaiting negotiations.
[Jan 22, 16:49:55] INFO EDIDataExtractor.logMessage() - 234 Enabling TLS, awaiting negotiations.

FROM address incorrect

The FROM: address in my emails sent from java don't appear correctly. This is not running in an application server but from a main() call:
// Get system properties
final Properties properties = System.getProperties();
// Setup mail server
properties.setProperty("mail.smtp.host", "localhost");
// Get the default Session object.
final Session session = Session.getDefaultInstance(properties);
// Create a default MimeMessage object.
final MimeMessage message = new MimeMessage(session);
// Set From: header field of the header.
message.setFrom(new InternetAddress("support#mydomain.com"));
// Set To: header field of the header.
message.setRecipients(javax.mail.Message.RecipientType.TO, "you#you.com");
// Set Subject: header field
message.setSubject("Your pants are on fire!");
message.setSentDate(new Date());
// Now set the actual message
message.setText("Take me to the bridge. ow!");
// Send message
Transport.send(message);
Here's the raw received email. Two things to note: the linux username under which the java process runs is mungo. The linux servername/hostname is servername. The domain is santamaria.com. These have been changed from their original to protect the guilty.
My question is: why isn't Return-Path support#mydomain.com and how can I make it so? Secondarily, how can I add a friendly name? e.g. Roger Earl <support#mydomain.com>
Delivered-To: you#you.com
Received: by 10.70.125.201 with SMTP id ms9csp51721pdb;
Sat, 22 Nov 2014 07:38:22 -0800 (PST)
X-Received: by 10.140.84.71 with SMTP id k65mr15089869qgd.76.1416670702208;
Sat, 22 Nov 2014 07:38:22 -0800 (PST)
Return-Path: <mungo#servername.santamaria.com>
Received: from servername.santamaria.com (servername.santamaria.com. [201.74.27.72])
by mx.google.com with ESMTPS id z90si10522625qgd.46.2014.11.22.07.38.21
for <you#you.com>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 22 Nov 2014 07:38:22 -0800 (PST)
Received-SPF: none (google.com: mungo#servername.santamaria.com does not designate permitted sender hosts) client-ip=201.74.27.72;
Authentication-Results: mx.google.com;
spf=none (google.com: mungo#servername.santamaria.com does not designate permitted sender hosts) smtp.mail=mungo#servername.santamaria.com
Received: from servername.santamaria.com (localhost [127.0.0.1])
by servername.santamaria.com (8.14.4/8.14.4) with ESMTP id sAMFcLkq012340
for <you#you.com>; Sat, 22 Nov 2014 15:38:21 GMT
From: RogerEarl <mungo#servername.santamaria.com>
Date: Sat, 22 Nov 2014 15:38:21 +0000 (UTC)
To: you#you.com
Message-ID: <1542856295.1.1416670701712.JavaMail.mungo#servername.santamaria.com>
Subject: Your pants are on fire!
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Take me to the bridge. ow!
UPDATE
The working code looks like this:
properties.setProperty("mail.smtp.from", "support#mydomain.com");
message.setFrom(new InternetAddress("support#mydomain.com", "My Friendly Support Name");

The InternetAddress class includes a constructor that allows you to set a "personal name" along with the email address; read the javadocs.
The Return-Path header is set by the receiving mail server, probably based on the "envelope from" address. Set the mail.smtp.from property to the address you want to use.

buffering issue with java communicating vlc

I'm a newbie to Socket communication, so I may be wrong, but please advice or at least give the direction!
I'm implementing an RTSP server according to http://www.csee.umbc.edu/~pmundur/courses/CMSC691C/lab5-kurose-ross.html#appendix taking a look to the similar code from http://www.java2s.com/Open-Source/Android/UnTagged/mynpr/com/webeclubbin/mynpr/RTSPserver.java.htm
At the moment I'm implementing responce to the OPTIONS request. To make it easy in the first approach, I decided to hardcode the answer according to the sample RTSP request/response log done for some real communication between vlc and gstreamer rtsp.
So, the log recorded with vlc URL -vvv says:
Sending request: OPTIONS rtsp://localhost:8554/test RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2013.04.30)
Received 183 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 2
Public: OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN
Server: GStreamer RTSP server
Date: Tue, 10 Sep 2013 19:56:53 GMT
Sending request: DESCRIBE rtsp://localhost:8554/test RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2013.04.30)
Accept: application/sdp
i.e.
RTSP/1.0 200 OK
CSeq: 2
Public: OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN
Server: GStreamer RTSP server
Date: Tue, 10 Sep 2013 19:56:53 GMT
part is 183 bytes length
I'm writing to the buffer right according to the example:
try{
System.out.println("S -> C");
System.out.println("RTSP/1.0 200 OK");
System.out.println("CSeq: "+RTSPSeqNb);
//System.out.println("Session: "+RTSP_ID);
if (responceType==OPTIONS) {System.out.println("Public: OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN");};
if (responceType==OPTIONS) {System.out.println("Server: GStreamer RTSP server"); };
if (responceType==OPTIONS) {System.out.println("Date: Tue, 10 Sep 2013 19:56:53 GMT");};
RTSPBufferedWriter.write("RTSP/1.0 200 OK"+CRLF);
RTSPBufferedWriter.write("CSeq: "+RTSPSeqNb+CRLF);
//RTSPBufferedWriter.write("Session: "+RTSP_ID+CRLF);
if (responceType==OPTIONS) {RTSPBufferedWriter.write("Public: OPTIONS, DESCRIBE, GET_PARAMETER, PAUSE, PLAY, SETUP, SET_PARAMETER, TEARDOWN"+CRLF);};
if (responceType==OPTIONS) {RTSPBufferedWriter.write("Server: GStreamer RTSP server"+CRLF); };
if (responceType==OPTIONS) {RTSPBufferedWriter.write("Date: Tue, 10 Sep 2013 19:56:53 GMT"+CRLF); };
RTSPBufferedWriter.write("Session: "+RTSP_ID+"\r"+CRLF);
RTSPBufferedWriter.flush();
//RTSPBufferedWriter.newLine();
System.out.println("RTSP Server - Sent response to Client.");
}
catch(IOException ex)
{
System.out.println("Exception caught: "+ex.getStackTrace());
// System.exit(0);
}
and the vlc log says
Opening connection to 127.0.0.1, port 6666...
...remote connection opened
Sending request: OPTIONS rtsp://127.0.0.1:6666/autostream.mjpg RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2013.04.30)
Received 193 new bytes of response data.
[0x7fd01c001178] live555 demux debug: connection timeout
[0x7fd01c001178] live555 demux error: Failed to connect with rtsp://127.0.0.1:6666/autostream.mjpg
Where CRLF is '\n'. Before I tried CRLF="\r\n" (and no +"\r"+ in the last line) with
Received 198 new bytes of response data.
So, what is wrong there? What vlc is waiting for? Why default delimeters from the example doesn't work for it?

I looks like I always find the answer to my questions after I publish them to stackoverflow...
DOUBLE CRLF should stand after the last header for the usual RTSP protocol 9not the customized one used in the example).