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

Requiring header fields for creating certain packets #27

Open
ericblau opened this issue Nov 8, 2021 · 3 comments
Open

Requiring header fields for creating certain packets #27

ericblau opened this issue Nov 8, 2021 · 3 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@ericblau
Copy link
Contributor

ericblau commented Nov 8, 2021

In my admittedly not terribly thorough look through the code, it seems that we have a mechanism to require certain fields in the body of the packet, per packet type, but there doesn't appear to exist a way to require particular header fields.

It would be useful to be able to require the originating_site_name in the header for notify_person_ids (and/or have it default to the remote_site_name), as this packet type originates at the remote site, and is not a reply to any other packet.

@sabo sabo self-assigned this Dec 9, 2021
@sabo sabo added the enhancement New feature or request label Dec 9, 2021
@sabo
Copy link
Collaborator

sabo commented Dec 9, 2021

It'd be pretty easy to require certain header fields on packet creation and/or validation, but I'd need more info on what is required when in what cases. Separately, having default values in certain cases is doable but might complicate things a bit.

For example, can we assume for all packets that originating_site_name should be remote_site_name unless otherwise specified? Or would the 'rule' be, for certain specific packets, we can assume that; otherwise we must require it?

@ericblau
Copy link
Contributor Author

ericblau commented Dec 9, 2021

This was in reference to the issue described at https://jira.xsede.org/browse/A3M-482

Namely, notify_person_ids is one of the few packets that a remote site can POST to start a new transaction--it isn't in reply to another packet, and thus the API (which knows as little as possible about the specifics of the packets it processes) needs to know what the originating_site_name is.

As of the resolution of that JIRA issue, the API rejects packets that are posted not-in-reply-to another packet, if they don't include an originating_site_name. It also enforces that the originating_site_name must match either "TGCDB" or the remote_site_name.

It would still be nice if the amieclient would do this too, but the API gives a reasonable error message now if not, so it's probably not a big deal.

@sabo
Copy link
Collaborator

sabo commented Dec 10, 2021

End result of the discussion is that adding a validation check for notify_person_ids that will check if originating_site_id is present and equal to either TGCDB or remote_site_name will be added to the next release, but it's nothing that needs to be pushed out on its own.

@sabo sabo added this to the 0.6.1 milestone Dec 10, 2021
@sabo sabo modified the milestones: 0.6.1, 0.7.0 Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants