Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add parameters to set Acceptable policy errors when connecting over TLS #164

Closed
wants to merge 2 commits into from

Conversation

kzhen
Copy link

@kzhen kzhen commented May 10, 2021

When making a connection to the RabbitMQ broker over TLS the RabbitMQ .Net Client rejects the connection if the certificates configured on the broker are self signed and not considered 'trusted'. This PR allows the passing of the SslPolicyErrors enum as a parameter to indicate which errors are acceptable for TLS connections.

kzhen added 2 commits May 9, 2021 16:14
…MQTriggerAttribute

This property is used to configure which Ssl policy errors are allowed when connecting to RabbitMQ over TLS
@ghost
Copy link

ghost commented May 10, 2021

CLA assistant check
All CLA requirements met.


_model = connectionFactory.CreateConnection().CreateModel();
_model = connectionFactory.CreateConnection(Assembly.GetEntryAssembly().GetName().Name).CreateModel();
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When creating the connection we pass through the Assembly name so the connection can be identified in the RabbitMQ management portal

@kzhen
Copy link
Author

kzhen commented May 12, 2021

@yojagad any thoughts on this?

@JatinSanghvi
Copy link
Contributor

Thanks for the PR. I found that #178 is trying to accomplish a similar goal. I personally like the idea of giving user the ability to define the acceptable SSL errors as being done in this PR, but there should be also a way to enable/disable SSL if user is passing binding parameters individually (instead of connection string with scheme amqp or amqps) as it is being done in the other PR. Since both changes are conflicting, I will need to close this one in favor of the other one, as that one is the latest one and I have already started following up on it actively. I will also reconsider on whether connection name should be passed on not.

@kzhen
Copy link
Author

kzhen commented Jan 29, 2022

Thanks for the update @JatinSanghvi, the original intention that I had with this PR was to use this NuGet package for some work related projects. Instead we've gone in the direction of writing our own custom trigger bindings which wrap EasyNetQ - that has the added advantage of taking care of an opinionated approach to queue/exchange creation as well as bindings between queues and exchanges.

The code in the repository helped a lot to get an understanding of the different parts involved in writing such a library - so thanks to all the team 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants