-
Notifications
You must be signed in to change notification settings - Fork 22
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
Support target authentication #33
Comments
At first, I thought this is a good idea - a common case. But, then I recalled that this issue is similar to #31. Seeing those two issues, I fear, a little, that after a while we might end up with having cURL number of options slipped to kn-event:
I'm not sure is that a correct way to go. Maybe we could do better somehow... Any ideas, @rhuss? |
Yeah, the API would certainly grow. But IMHO there's a couple of basic flags which should be supported, e.g. TLS, insecure and (basic) auth. Let's see what Roland says... |
This issue is stale because it has been open for 90 days with no |
/remove-lifecycle stale |
This issue is stale because it has been open for 90 days with no |
/remove-lifecycle stale |
This issue is stale because it has been open for 90 days with no |
/remove-lifecycle stale |
I'm +1 for adding security-related options as this is something that is not uncommon. At the moment I don't see that we will run into option bloat, so adding commonly used transport related options makes much sense to me. |
The
send
command currently assumes no authentication in the endpoint.kn event send
is useful outside of direct Knative cluster access, e.g. to send Cloud Events to arbitrary webhooks or endpoints (services) in Kubernetes/Knative which enforce authentication, e.g. basic_auth.What do you think about adding support for authentication schemes?
The text was updated successfully, but these errors were encountered: