Skip to content

Implementing the Firebase Security Rules API - #604

Merged
hiranya911 merged 5 commits into
rulesfrom
firebase-rules-api
Jul 29, 2019
Merged

Implementing the Firebase Security Rules API#604
hiranya911 merged 5 commits into
rulesfrom
firebase-rules-api

Conversation

@hiranya911

@hiranya911hiranya911 commented Jul 24, 2019•
edited
Loading

Copy link
Copy Markdown
Contributor

Added the base framework for the new security rules API (nothing new exposed in the public API --i.e. admin namespace -- yet). This PR specifically adds the SecurityRules class and the following 2 methods:

  • getRuleset()
  • getFirestoreRuleset()

Also defined the types Ruleset, RulesetMetadata and RulesFile which will be added to the public API in the future.

go/firebase-rules-admin

ryanpbrewster
ryanpbrewster reviewed Jul 25, 2019
View reviewed changes
Comment threadsrc/security-rules/security-rules-api-client.ts Outdated
* @returns {Promise<T>} A promise that fulfills with the resource.
*/
public getResource<T>(name: string): Promise<T> {
if (!name.startsWith('projects/')) {

@ryanpbrewsterryanpbrewsterJul 25, 2019

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

may be worth regexing this to catch malformed project ids (which, for instance, I think need to be lowercase).

@hiranya911hiranya911Jul 25, 2019

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I simplified things a bit here by pushing the projectId to the constructor of the RulesApiClient. Now it stores a partial URL as part of its state:

this.url = `${RULES_API_URL}/projects/${projectId}`;

Callers should pass in the resource names without project ID:

client.getResource('rulesets/my-ruleset');

As for project ID validation, we are doing the same check here as our other modules (Auth, FCM), and so it should be sufficient.

@ryanpbrewsterryanpbrewsterJul 25, 2019

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll defer to you here, but:

  • there aren't that many kinds of resources
  • it may be easier to explicitly spell them all out as unique methods:
client.getRuleset(<ruleset_name>)
client.listRulesets()
client.getRelease()
client.listReleases()

which directly encodes the exposed backend API. Then add another layer on top of that.

@hiranya911hiranya911Jul 25, 2019

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good idea. Will implement in the next PRs.

Comment threadsrc/security-rules/security-rules-api-client.ts Outdated
Comment threadsrc/security-rules/security-rules-api-client.ts
Comment threadsrc/security-rules/security-rules.ts Outdated
Comment threadsrc/security-rules/security-rules.ts Outdated
Comment threadsrc/security-rules/security-rules.ts Outdated
@hiranya911

hiranya911 commented Jul 25, 2019

Copy link
Copy Markdown
ContributorAuthor

Thanks @ryanpbrewster. I've made a pass and addressed your comments.

@ryanpbrewsterryanpbrewster removed their assignment Jul 25, 2019
ryanpbrewster
ryanpbrewster approved these changes Jul 25, 2019
View reviewed changes

@ryanpbrewsterryanpbrewster left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM as-is, if you opt to refactor to match the backend API feel free to re-assign me (alternately: feel free to do this in a separate PR)

rachelmyers
rachelmyers approved these changes Jul 26, 2019
View reviewed changes

@rachelmyersrachelmyers left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good. There were a few interfaces that I didn't expect, and left a comment in-line for those.
:shipit: 🚢

Comment threadsrc/security-rules/security-rules.ts
readonly source: {
readonly files: RulesFile[];
};
}

@rachelmyersrachelmyersJul 26, 2019

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are Release and RulesetResponse additions to what we proposed?

@hiranya911hiranya911Jul 29, 2019

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are part of the internal implementation. They are not exported and also won't be added to the typings.

Comment threadsrc/security-rules/security-rules.ts Outdated
}

/**
* Representa a set of Firebase security rules.

@rachelmyersrachelmyersJul 26, 2019

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/Representa/Represents

@hiranya911hiranya911Jul 29, 2019

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

@hiranya911
hiranya911 merged commit e5f0ed3 into rulesJul 29, 2019
@hiranya911
hiranya911 deleted the firebase-rules-api branch July 29, 2019 18:09
@hiranya911hiranya911 mentioned this pull request Jul 29, 2019
Merged
hiranya911 added a commit that referenced this pull request Sep 18, 2019
@hiranya911
feat: Security Rules Management API (#645)
0b2082f
* Implementing the Firebase Security Rules API (#604)
* Implementing the Firebase Security Rules API
* More argument validation and assertions
* Cleaning up the rules impl
* Internal API renamed
* Fixing a typo in a comment
* Implemented createRulesFileFromSource() and createRuleset() APIs (#607)
* Implementing the Firebase Security Rules API
* More argument validation and assertions
* Adding the rest of the CRUD operations for rulesets
* Cleaning up the rules impl
* Cleaned up tests
* Adding some missing comments
* Removing support for multiple rules files in create()
* Implemented the deleteRuleset() API (#609)
* Added deleteRuleset API
* Merged with source
* Implemented the API for releasing rulesets (#610)
* Implemented the API for releasing rulesets
* Removed createRelease logic
* Updated comment
* Added the getStorageRuleset() API (#613)
* Implemented the API for releasing rulesets
* Removed createRelease logic
* Added getStorageRules() API
* Removed some redundant tests
* Implementing the remaining releaseRuleset APIs (#616)
* Implemented the listRulesetMetadata() API (#622)
* Adding the rules API to the public API surface (#625)
* Added rules API to the public admin namespace
* Updated docs
* Addressing comments regarding the d.ts file
* Updated App typings
* Rules integration tests (#633)
* Rules integration tests
* Refactored by adding some helper methods
* Cleaned up some conditionals
* Added verification for deleteRuleset test
* Renamed tempRulesets
* Handling ruleset limit exceeded error (#636)
* Fixing alignment of an annotation
* Updated comments
@Jeremip11Jeremip11 mentioned this pull request Nov 27, 2023
Open
@takerattatakeratta mentioned this pull request Nov 29, 2023
Open
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

2 more reviewers
@rachelmyersrachelmyersrachelmyers approved these changes
@ryanpbrewsterryanpbrewsterryanpbrewster approved these changes
Reviewers whose approvals may not affect merge requirements

Assignees

@hiranya911hiranya911

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@hiranya911@rachelmyers@ryanpbrewster