This commit does three things:
1. Documents a method
3. Implies the question: "Do we want to use class_attribute in Forem's codebase?"
2. Switches from an inferrence to an explicit (and configurable)
In my experience, I want to favor "explicit" declarations instead of
inferring what they should be. In this case, the inferrence is perhaps
adequate. But as I look to `ApplicationController::PUBLIC_CONTROLLERS`,
I think that is a prime case for a `class_attribute`. (The `api_action`
happened to be the lowest hanging fruit to begin the conversation.)
We still need some clarity into the `verify_private_forem` method as it
looks like it's doing a few different things.
There is precedence for using `class_attribute` found in
[`UniqueCrossModelSlugValidator.model_and_attribute_name_for_uniqueness_test`][1] (also
introduced by me).
[1]:https://github.com/forem/forem/blob/main/app/validators/unique_cross_model_slug_validator.rb
As part of the [Authorization System Use Case
1:1](https://github.com/orgs/forem/projects/46) project, we are driving
towards the feature of: "Only admin's may post articles in this Forem."
This commit ensures that the API's "create an article" end-point
delivers on that feature.
Along the way, I've added reading notes and comments, to help us further
flex in the future (namely move all authorization checks into a policy
object).
Closesforem/forem#16488
In conversations with citizen428, this method looked to be a holdover
from a past approach. Reviewing the code, we can get the same behavior
with other methods.
Further, I added some comments for future considerations, and refactored
for more readily scannable guard clauses.
Related to forem/forem#16488, forem/forem#16681, and forem/forem#6255
As I was investigating an approach for #16488, I stumbled upon two
methods partially doing the same thing. This helps consolidate the
logic and provides some guiding documentation.
* Refactoring questions asked of user
In this pull request, I'm extracting and normalizing role-based
questions asked of the user.
Prior to this commit, our codebase has asked two very similar questions
of our user model:
- `user.has_role?(:admin)`
- `user.admin?`
In asking `has_role?(:admin)` we are relying on implementation details
of the rolify gem. In addition, the `has_role?` question asked
throughout controllers or views means that it's harder to create
hieararchies of permissions.
In favoring `user.admin?` as our question, we can use that indirection
as an opportunity to discuss and decide "Should someone with the
`:super_admin` role be `user.admin? == true`?"
The details of this commit is to do three primary things:
1. Ask the `has_role?` questions in "one place" in the code (e.g. the
`Authorizer` module)
2. Extract the role based questions that are on the `User` model and
provde backwards compatable delegation.
3. Structure the code so that it's harder to accidentally call
`user.has_role?` (e.g., make `User#has_role?` and `User#has_any_role?`
private).
This is related to #15624 and the updates are informed by discussion in
PR #15691. This commit supplants #15691.
* Refactoring the liquid tag policy tests
* Fixing typo
* Bump for travis
* Rename banned and comment_banned roles
* Add data update script to rename roles containing 'ban'
* Add named error for Suspended users
* Update unidiomatic method names
* Rename misc banned to suspended
* Apply suggestions from code review
Co-authored-by: Michael Kohl <me@citizen428.net>
* Add unit tests for suspended methods
This commit also adds TODO comments for removing banned and
comment_banned from the codebase after data update scripts have
successfully run on all of our Forems.
Co-authored-by: Michael Kohl <me@citizen428.net>
* Prevent banned users from accessing API
* Prevent banned users from creating API keys
* Delete API keys when deleting user
* Add tests
* Prevent banned signed in users from accessing API oops
* Refactor authenticate! for readability
* Add correct rate limit exception to Articles::Updater
* Send Retry-After with HTTP 429 back to the client
* Update API specs for error 429
* Test build
* Fix spec
* Add retry after to ImageUploadsController and fix specs
* Generalize a bit
* Access only unpublished listings if they belong to the user when authenticated
* Make sure we never send unpublished listings in the index
* Update API docs
* oops
* Remove unused preloading as this loads a single item
* Fix articles index state param values
* Update Articles API docs
* Fix ClassifiedListing.cost_by_category with invalid category
* Add docs for GET|POST /listings and fix bugs
* Document PUT /api/listings/:id
* Add docs for /listings/category/{category}
* One variable down
* Improve listings update error handling
* TagsController inherits from ApiController
* Let ApiController inherit from ActionController::Base to have its own lifecycle
* Remove unused method
* Use only one respond_to :json for the entire API
* ApiController inherits from ActionController::Base
* Use Pundit only where needed
* Update specs for doorkeeper test
* Add bang
* Create #authenticate
* Create /api/articles/ endpoint
* Update specs
* Update me.json.jbuilder
* Fix typo and spacing
* Support pagination for #me
* Update #authenticate! to support cookies
* Make per_page a param
* Disable method-complexity check
* Enable refresh_token
* Create /api/users/me endpoint
* Use proper auth chain before checking parameters
* Refactor AnalyticsController
* Add a bunch of test and rewrite reactions counts with a single query
* Add tests for follows totals
* Use round and add more refactoring
* Add tests to group by day to fallback during refactoring
* Use group by to calculate comments count by day
* Use group by to calculate follows count by day
* Use group by to calculate reactions stats by day
* Use group by to calculate page_views stats by day
* Move calculations per day back in the cached block
* Add a few comments and a little bit of refactoring
* Add indexes (concurrently) for analytics
* Make tests more time robust
* Use a date range cache related to the requesting user or org
* Freezing time in UTC should help when tests are ran on time zones over the day line
* Remove explicit returns
* Page title is escaped, guard against that
* Move Analytics service spec in the proper place
* Add system test to create article from the editor
* Move article creation from API to app controller
* Fix system test to edit posts
* Move article update from API to app controller
* Rewrite create article API using API key
* Add main_image and canonical_url to allowed creation params
* Rewrite update article API using API key
* Fix tests and have Comments API inherit from API
* Add API endpoints for analytics
* Remove comment and spacing
* Use proper time formatting
* Refactor and clean up some logic
* Add pro and org member traits
* Use shared examples for analytics API spec
* Add analytics authorization specs
* Remove accidental include Pundit
* Raise not_authorized for invalid requests
* Make attributes and time methods private
* Add custom UnauthorizedError
* Raise and use rescue_from to handle 4xx requests
* Enforce date parameters to follow a specific format
* Use current user to allow same origin requests
* Use custom headers and not params for token auth
* Default to current user for same origin requests
* Use correct boolean for choosing user
* Update tests to use request headers and add stricter tests
* Initial automatic cleanup with rubocop
* Fix syntax error introduced by rubocop
* Cleanup seeds file
* Cleanup lib folder
* Exclude bin folder because it contains auto generated files
* Make Rubocop a little bit more chatty
* Block length should not include comments in the count
* Cleanup config folder
* Cleanup specs
* Updated Rubocop version and generated a todo file
* Fix broken ArticlesApi spec
* Fix tests
* Restored rubocop pre-commit hook
