* Start refactoring articles update
* Articles update refactoring
* Added a couple of tests for Articles::Updater
* Reorganized code in Articles::Updater and ::Attributes a bit
* A couple of more tests for Articles::Attributes
* Reverted changed in the articles_controller
* Edited_at in Articles::Attributes
* Use Articles::Updater in ArticlesController
* Tests for notifications when published/unpublished an article
* Removed old code
* Return result object from Articles::Updater
* Don't reset articles collection when no series was passed
* Fixed sending notifications when published an article the first time
* Fix articles collection when updating
* Fix setting attributes for articles update
* Spec for articles update via api failure
* More tests for Articles::Updater
* More specs for articles updating
* Pass article instead of article_id to articles updater to avoid loading an article twice
* Remove the redundant check in the articles_controller
* Articles::Attributes refactoring
* 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
* Disable ActionController auto params wrapping
Rails by default accepts wrapped and unwrapped parameters in JSON requests (with or without a root object), regardless of the fact that the contract with the client requests wrapped parameters or not. This results in unforeseeable bugs when the client sends unwrapped parameters in lieu of wrapped ones.
As undeterministic bugs are a PITA and this is the classic grey area in Rails apps and as the customer facing API is fully documented and the internal can be manually adjusted, we disable this and be done with this odd feature.
https://github.com/forem/forem/issues/11645https://github.com/forem/forem/pull/11638
* Remove accidentally committed file
* add organizations api request spec
* add organizations api controller
* add organizations api show route
* add show jbuilder file
* fix merge conflict on routes
* add organization show to api docs
* update created_at to iso format
* api docs add format field/cleanup
* Documents the new /profile-images/:username API endpoint
* Introduces the /api/profile_images/:username endpoint
This endpoint receives either an user or organization username as input
via the URL path and returns the profile image information for that
user/orgnization.
* Updates the /api/profile_images/:username response
Adapts the response according to the review comments:
1. Removes the cache directives
1. Tweaks how the user query is being done
1. Adds a `image_of` property to the response
* Bump API version
Co-authored-by: rhymes <rhymes@hey.com>
Co-authored-by: Molly Struve <mollylbs@gmail.com>
* Add route for fetching a user's followed tags
* Move followed tags route to FollowsController instead of TagsController and add JSON view
* Add missing new line
* Change the dots for our linter
Co-authored-by: rhymes <rhymes@hey.com>
Co-authored-by: Molly Struve <mollylbs@gmail.com>
* added created_at to comments in api response
* added test to ensure a date is returned for comment
* fix offenses in test
* updated docs to include addition of created_at to comment api response
* Replace in Cache-Control header to support Nginx caching
* Add 'X-Accel-Expires' header for Nginx caching
* Remove max-age directive from remaining specs
* Update caching header specs to test against x-accel-expires header
* Enable new Rails/* cops and use autocorrect on them
* Fixed Rails/PluckInWhere leftovers
* Fix Rails/DefaultScope
* Enable and fix Rails/PluckId
* Fix manual mistake with forcing autocorrection on Rails/PluckId
* Apply PR feedback to remove Rails/PluckId inline disables
* Apply PR feedback to get rid of Rails/PluckInWhere inline
* Add check to id param to use slug if passed
* modify to use slug in a different action
* wrote test for this api endpoint
* update test to check array equality
the test also checks if the first tag in the parsed list is the same as the first tag in the article
* Add dual booting logic to Gemfile
This might be helpful for the Rails 6.0 upgrade project.
* Add more than one gemfile to Travis' configuration
We want to see how the application behaves with more than one Rails versions:
- Gemfile -> Rails 5.2
- Gemfile.next -> Rails 6.0
This will help us figure out what needs to be addressed before migrating to Rails 6.0.
If you want to read more about this technique (dual booting) you can check out this page: https://www.fastruby.io/blog/upgrade-rails/dual-boot/dual-boot-with-rails-6-0-beta.html
* Fix joins
* Upgrade Gemfile.next.lock
* Make sure we're installing the correct versions of gems
* Add Rails 6 notes
* Update rubocop in Gemfile.next.lock
* Fix organization spec
* Fix page_views_spec
* Add Rails 6 and run rails app:update
* Remove some tricks
* Remove Gemfile.next for now
* Fix .content_type deprecation
* Fix deprecation of .where.not NAND/NOR behavior
* Fix deprecation of parameterized emails
* Fix specs
* Remove next flag for now
* Fix spec (hopefully)
* Add wait_for_javascript
* Fix spec, thanks @maestromac!
* Try without wait for javascript hack
* Remove unnecessary bin/update
* Remove file that snuck in the rebase
* Update the vendored gems
* Replace migrate+db:setup with db:prepare
* Update vendored gems
* Fix Gemfile.lock and update vendored stuff
* Fix Gemfile.lock to be the same as master's minus the changes
Co-authored-by: rhymes <rhymesete@gmail.com>
* This change allows access to api/health_checks if you are coming from localhost
or 127.0.0.1. Pretty sweet huh?
The reason for this change is because I want to easily get to these healthcheck
end points from localhost without having to get the health-check-token beforehand.
Buttttt.... this addition has some issues. You can spoof the host header pretty
easily:
https://daniel.haxx.se/blog/2018/04/05/curl-another-host/
I thought about doing `return if !request.ssl? && request.local?`
to check of the request was over https or not. Any localhost healthcheck we do
directly to puma will be over http. Checking for TLS seemed like a logical next
check, but since we force https on the edge and not necessarily from the edge to
Puma the Host header can still be spoofed to get at these end points.
More info on host header attacks and what Rails 6 is doing about it:
https://github.com/rails/rails/issues/29893
While I do think it is a good idea to protect these healthcheck end points from
the outside world, I do want to be able to get to them easily locally. WWYD?
* Fix Health Check spec by stubbing request
Co-authored-by: mstruve <mollylbs@gmail.com>
* Change models and related files
* Update controllers and specs
* More renaming
* Seek and destroy, I mean search and replace
* Round up the stragglers
* Ground control to Major Travis...
* More fixes
* PR feedback
* Various fixes
* Rename view
* Fix list query builder
* Unify request specs
* Fix some API spec errors
* Fix remaining API specs
* Make spec conform to API
* Fix leftover problems
* Fix JS tests
* Fix column name in select
* Fix API specs
* Fix search specs
* Paging Mr. Travis
* Rename positive_reactions_count to public_reactions_count
* Add positive reactions count back in so we can remove it
* Use public_category method for reactions
* Add positive_reactions_count in case any old caches rely on it
* Add positive_rxn_count to account for API endpoints
* Remove unused method
* One more spot...
* Add method back in because of caches
* Update specs to match new functionality
* Fix typo
* Remove unused methods
