Skip to content

Loose event validation #325

Closed
Closed

Description

@lance

Is your feature request related to a problem? Please describe.
Currently, when creating a CloudEvent instance, one of the final things that happens in the constructor before freezing the object is this.validate() is called. The validate() function will throw an exception if the event is invalid. This effectively means that there is no way to create an event that's invalid. In most cases, this is probably for the best. But what happens if you have a system with a known bug that's emitting invalid events, and some JavaScript service using this module is receiving them. There's no way to actually do that without forking this repo.

Describe the solution you would like to see

  • Optionally, don't call this.validate() in the constructor based on an added boolean parameter (strict: boolean = true by default).
  • Change Detector interface from feat: introduce Message, Serializer, Deserializer and Binding interfaces #324 to use an optional parameter for loose validation.
  • Change the Deserializer interface which converts from a Message to a CloudEvent to use an optional parameter for loose validation.

Additional context
This is all in the context of creating events manually, or deserializing an incoming Message into a CloudEvent. I haven't thought much about the serialization step. If a user manually creates an invalid event, and then serializes it to a Message, should that throw an exception? I think maybe it should, but interested in other's opinions.

Activity

  1. added
    type/discussionIssues that need to be decided/debated/discussed
    module/libRelated to the main source code
    version/4.xIssues related to the 4.0 release of this library
    on Aug 24, 2020
  2. lholmquist commented on Aug 25, 2020

    @lholmquist
    Contributor

    When i was first adding the validation to the CloudEvent constructor, i contemplated adding what you are talking about in. My main reason was because of how the test were written.

    I can see this being a feature, but my only concern is if a user has a service where they send cloud events, and turn off the event validation. then another user uses that service to receive events, how will they know that the service has the validation turned off. They will probably get errors when trying to "accept" the event and think that maybe there is a bug in this library.

  3. self-assigned this
    on Aug 26, 2020
  4. grant commented on Aug 26, 2020

    @grant
    Member

    Thanks for creating the issue!

    According to the SDK spec, there are various methods described. One of them is creation and one is validation.
    https://github.com/cloudevents/spec/blob/master/SDK.md#technical-requirements

    I would assume the composition method and validation method are separate and folks can use them separately as they wish for whatever reason they want.

    As such, I think the validation method should not be called by default within the composition method. (Maybe we can have it for convenience.) It should be default false. This is important because consumers of CloudEvent from major CE producers can expect to have a valid event and don't need this.

    i.e. we don't need new CloudEvent({...}, false) everywhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

module/libRelated to the main source codetype/discussionIssues that need to be decided/debated/discussedtype/enhancementNew feature or requestversion/4.xIssues related to the 4.0 release of this library

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions