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
samples: changed PAP unspecified to inherited #14141
Merged
Merged
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
126f857
samples: changed PAP unspecified to inherited
bajajneha27 20e11a6
Adding the right path of inherited sample.
bajajneha27 d702551
Samples test case fix.
bajajneha27 b05f5e1
Deprecating method public_access_prevention_unspecified?
bajajneha27 4e64f93
Addressing review comments.
bajajneha27 File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
31 changes: 31 additions & 0 deletions
31
google-cloud-storage/samples/storage_set_public_access_prevention_inherited.rb
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,31 @@ | ||
# Copyright 2020 Google LLC | ||
# | ||
# Licensed under the Apache License, Version 2.0 (the "License"); | ||
# you may not use this file except in compliance with the License. | ||
# You may obtain a copy of the License at | ||
# | ||
# http://www.apache.org/licenses/LICENSE-2.0 | ||
# | ||
# Unless required by applicable law or agreed to in writing, software | ||
# distributed under the License is distributed on an "AS IS" BASIS, | ||
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
# See the License for the specific language governing permissions and | ||
# limitations under the License. | ||
|
||
# [START storage_set_public_access_prevention_inherited] | ||
def set_public_access_prevention_inherited bucket_name: | ||
# The ID of your GCS bucket | ||
# bucket_name = "your-unique-bucket-name" | ||
|
||
require "google/cloud/storage" | ||
|
||
storage = Google::Cloud::Storage.new | ||
bucket = storage.bucket bucket_name | ||
|
||
bucket.public_access_prevention = :inherited | ||
|
||
puts "Public access prevention is 'inherited' for #{bucket_name}." | ||
end | ||
# [END storage_set_public_access_prevention_inherited] | ||
|
||
set_public_access_prevention_inherited bucket_name: ARGV.shift if $PROGRAM_NAME == __FILE__ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of making this breaking change, I would recommend adding a new method
#public_access_prevention_inherited?
, and deprecating#public_access_prevention_unspecified?
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I made an alias of this method at #1035
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, sorry, I missed that. If
inherited
andunspecified
have the same meaning, then the alias is OK.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using an alias still changes the behavior of
#public_access_prevention_unspecified?
which is a breaking change. I think we should keep the original method but deprecate it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, best to deprecate with a reference to the new method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, now that I think about it some more, the right thing to do kind of depends on the behavior of the backend.
(1) If the values are being changed transparently by the backend, i.e. anything that used to be returned as "unspecified" are now magically returned as "inherited" by the backend, then yes, we should keep the alias in order to preserve the semantics of the call. (But in this case we might also need to update the setter so that if the user passes in
:unspecified
, we turn it into:inherited
before we send it, in case the backend doesn't map that for us.)(2) If the values are not being changed transparently, i.e. we are expecting the user to shift their usage, then we should keep the existing method but deprecate it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think point 1 stands correct here but @shaffeeullah can confirm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shaffeeullah @tritone Can either of you shed any light on this? Specifically:
unspecified
prior to the change, does the backend still return the valueunspecified
or does it map the value toinherited
and return that?unspecified
, will the backend automatically interpret it asinherited
or are we depending on users to alter their usage in order to get the desired functionality?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unspecified
, it will returnunspecified
. In the future,unspecified
will be deprecated and everything that wasunspecified
will be returninginherited
instead.unspecified
andinherited
. Eventually, settingunspecified
will returninherited
. This is not the case yet.Another note, for allowlisted projects, the default value is currently
inherited
. This will roll out to be the behavior for all projects early November. This changes the default from the previousunspecified
. For all projects (regardless of allowlist), settinginherited
will work as intended (even if it isn't the default).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @shaffeeullah! Given this info, I think what we should do is:
#public_access_prevention_inherited?
should return true for either value (inherited
orunspecified
).#public_access_prevention_unspecified?
should alias#public_access_prevention_inherited?
, so it also returns true for either value.