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

Brh update #4773

Merged
merged 5 commits into from
Jun 22, 2022
Merged

Brh update #4773

merged 5 commits into from
Jun 22, 2022

Conversation

cgmeyer
Copy link
Contributor

@cgmeyer cgmeyer commented Jun 21, 2022

No description provided.

@PlanXCyborg
Copy link
Contributor

brh.data-commons.org/manifest.json

⚠️ Services on branch

  • hatchery

Deployment changes

Breaking changes

  • fence
    • URL Signing when no_force_sign query param is provided: Previously Fence would make a decision based off if the data was public and no_force_sign provided. Fence will now NEVER sign if no_force_sign is provided (since the concept of "public" data has been abstracted out of Fence. Data access - public or not - is the sole responsibility of the policy engine). In other words, if no_force_sign is provided at the API level, Fence will respect that regardless of whether the resulting URL will actually work. The default Fence behavior should remain the same. chore(jupyter-nde1.1.0) #988 (Feat/passport fence#964)

brh.data-commons.org/manifest.json Outdated Show resolved Hide resolved
brh.data-commons.org/manifest.json Outdated Show resolved Hide resolved
brh.data-commons.org/manifest.json Outdated Show resolved Hide resolved
cgmeyer and others added 3 commits June 21, 2022 16:53
Co-authored-by: Mingfei Shao <2475897+mfshao@users.noreply.github.com>
Co-authored-by: Mingfei Shao <2475897+mfshao@users.noreply.github.com>
Co-authored-by: Mingfei Shao <2475897+mfshao@users.noreply.github.com>
@PlanXCyborg
Copy link
Contributor

brh.data-commons.org/manifest.json

Deployment changes

Breaking changes

  • fence
    • URL Signing when no_force_sign query param is provided: Previously Fence would make a decision based off if the data was public and no_force_sign provided. Fence will now NEVER sign if no_force_sign is provided (since the concept of "public" data has been abstracted out of Fence. Data access - public or not - is the sole responsibility of the policy engine). In other words, if no_force_sign is provided at the API level, Fence will respect that regardless of whether the resulting URL will actually work. The default Fence behavior should remain the same. chore(jupyter-nde1.1.0) #988 (Feat/passport fence#964)

2 similar comments
@PlanXCyborg
Copy link
Contributor

brh.data-commons.org/manifest.json

Deployment changes

Breaking changes

  • fence
    • URL Signing when no_force_sign query param is provided: Previously Fence would make a decision based off if the data was public and no_force_sign provided. Fence will now NEVER sign if no_force_sign is provided (since the concept of "public" data has been abstracted out of Fence. Data access - public or not - is the sole responsibility of the policy engine). In other words, if no_force_sign is provided at the API level, Fence will respect that regardless of whether the resulting URL will actually work. The default Fence behavior should remain the same. chore(jupyter-nde1.1.0) #988 (Feat/passport fence#964)

@PlanXCyborg
Copy link
Contributor

brh.data-commons.org/manifest.json

Deployment changes

Breaking changes

  • fence
    • URL Signing when no_force_sign query param is provided: Previously Fence would make a decision based off if the data was public and no_force_sign provided. Fence will now NEVER sign if no_force_sign is provided (since the concept of "public" data has been abstracted out of Fence. Data access - public or not - is the sole responsibility of the policy engine). In other words, if no_force_sign is provided at the API level, Fence will respect that regardless of whether the resulting URL will actually work. The default Fence behavior should remain the same. chore(jupyter-nde1.1.0) #988 (Feat/passport fence#964)

@cgmeyer cgmeyer merged commit 762fd0e into master Jun 22, 2022
@cgmeyer cgmeyer deleted the brh_update branch June 22, 2022 15:01
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.

3 participants