Conversation
Generated by 🚫 Danger |
|
Thank you for this PR. During today's DMPRoadmap Monthly all-team meeting I mentioned how there are also related DMPTool v2 API test files. Would you like me to add them to this PR? |
|
I'm seeing a lot of rubocop errors in here. This might be a difference in the configuration of Rubocop between the Roadmap repo and DMP Online. Let me know how you'd want to approach this. If possible, I could start a PR attempting to fix these. |
|
Here is the document with the API calls. Please let us know if needs changing |
@momo3404 apologies we missed this. I can do this and push it back next week, if that's ok. |
|
These two docs are more for developers support. It might be useful |
Awesome, thank you. Sorry, the links got a little bungled up in the comment. :P |
@aaronskiba Here you go: Let us know if this doesn't work. |
|
I'm encountering the following when I test the App backtrace
Full backtrace |
| # Remove `null: false` if you are planning to use grant flows | ||
| # that doesn't require redirect URI to be used during authorization | ||
| # like Client Credentials flow or Resource Owner Password. | ||
| t.text :redirect_uri, null: false |
There was a problem hiding this comment.
Since we will be implementing the v2 API Client Credentials Flow in a future piece of work, maybe we should remove null: false on redirect_uri, as the code comment advises.
|
|
||
| # json.items [] | ||
| json.message @payload[:message] | ||
| json.details @payload[:details] |
There was a problem hiding this comment.
I can see @payload[:message] being assigned within app/controllers/api/v2/base_api_controller.rb. But is @payload[:details] being set anywhere? Maybe it can be removed.
app/policies/api/v2/plans_policy.rb
Outdated
| Plan.joins(:roles) | ||
| .where(roles: { user_id: @resource_owner.id, active: true }) | ||
| .distinct |
There was a problem hiding this comment.
It might be even better to reuse the Plan.active(@resource_owner) scope for this query. Note that a bit of refactoring could be performed in that scope to make this more efficient (i.e. don't use includes(:template, :roles))
|
Please let me know if I've done something wrong here, but I keep getting 302s when executing the GET command from the Authorization Code Grant Flow. But the command still worked, because after calling |
@aaronskiba this is fixed and should be working now |
Cool. I can get the 200 via the heartbeat whether I'm signed in or signed in now. Unfortunately, I think the fix may have introduced other bugs. I am testing the following curl request: This works and returns the expected JSON response on #3589, which is not up-to-date with these lastest heartbeat changes. However, when I test on this PR, I get the following response: I also get the following in the rails console: This must be related to I am also looking at the The assignments to |
Hey @aaronskiba, so sorry about this. I have changed Also, please feel free to commit any changes you feel are necessary (some of which you have already added as comments in this PR). |
This comment was marked as resolved.
This comment was marked as resolved.
Co-Authored-By: gjacob24 <97518971+gjacob24@users.noreply.github.com>
Fix crashes when `@client` is nil (e.g., on heartbeat endpoint where doorkeeper_token is not present). - `@client = doorkeeper_token&.application` simplifies `@client` assignment. - Guard log_access and add `@caller` for safe JSON output Align JSON response keys with V1 - server -> application - client -> caller Co-Authored-By: gjacob24 <97518971+gjacob24@users.noreply.github.com> Co-Authored-By: John Pinto <8876215+johnpinto1@users.noreply.github.com>
8ae4b5d to
a04513b
Compare
This test suite was adapted from the v2 API tests in CDLUC3/dmptool. The original request and view specs were copied and then refactored to align with our v2 API. Supporting factories and spec helper files were updated as needed to accommodate the new coverage.
These changes resolve the following issues uncovered via the API v2 tests: - app/views/api/v2/datasets/_show.json.jbuilder - Failure rendering output.doi_url when output is present (undefined method `doi_url`) - config/routes.rb - Spec failures due to undefined route helpers in test context (e.g., `api_v2_templates_path`)
Add v2 API Test Coverage and Address Uncovered Bugs
Executed `bundle exec rake translation:sync` while `config.disable_yaml = true`, allowing us to sync the doorkeeper translations.
Add navigation link for Doorkeeper OAuth Applications management access in the admin dropdown menu. - Link only renders for super admins.
Allow HTTP OAuth redirects in test/dev for easier local development, while maintaining HTTPS enforcement in all other environments.
4a5c7ee to
f443c9a
Compare
Remove OauthApplication, OauthAccessToken, and OauthAccessGrant model files. These classes were empty wrappers around Doorkeeper models that inherited directly from ApplicationRecord, bypassing Doorkeeper's validations, associations, and behavior. These wrapper classes were never referenced and posed a maintenance risk if used inadvertently in the future. Reference Doorkeeper's models directly instead (Doorkeeper::Application, Doorkeeper::AccessToken, and Doorkeeper::AccessGrant).
`a.present? && !a.blank?` was redundant.
- Changed to simply `a.present?`
Replaces map + post-filter with filter_map
- Eliminates the need for `ret.select { |item| item[:description].present? }`
Extracts question-theme lookup and q & a formatting into private helper methods.
- Improves readability and helps address rubocop offences
Rescuing from Exception would also catch system-level exceptions, which would likely be taking things too far (e.g. system-level errors like `Interrupt` and `SystemExit`). StandardError covers all application-level errors while still ensuring clients get consistent JSON responses.
Prior to this change, the `GET /me` endpoint exposed potentially sensitive user attributes (e.g. `api_token`) as well as internal-only fields (e.g. `other_organisation`, `department_id`, `dmponline3`, etc.). Now the endpoint only returns useful information (note the language.name rather than language_id and org.name rather than org_id improvements as well).
Replaced raw SQL with ActiveRecord query methods + enum scopes - Improves readability and eliminates SQL injection risk
Move theme filtering from Ruby to SQL using joins for better performance and scalability.
Previously, `fetch_q_and_a` iterated over all plan questions and searched for matching answers in Ruby, performing theme filtering and Q&A formatting in memory. This caused unnecessary loops, potential N+1 lookups, and inefficient handling of multi-theme questions. Accessing questions directly via `Plan.questions` also triggered joins through sections, phases, and templates, along with ordering (due to default scope), which added query overhead. The refactored version: - Queries answers directly via a join to question themes, filtering at the DB level. - Accesses questions through the answers (`answer.question`) instead of `plan.questions`, avoiding heavy joins and unnecessary default-scoped sorting.
Previously, the /api/v2/plans endpoint triggered many N+1 queries when rendering plan associations, causing slow response times. This change adds .includes() for all associations that were previously triggering Bullet N+1 warnings. Benchmark comparison (local dev, 10 sequential requests): | Metric | Before | After | | ----------------- | ------- | ------ | | Mean request time | 1909 ms | 492 ms | | Requests/sec | 0.52 | 2.03 | | Max request time | 2628 ms | 641 ms | - This simple comparison shows that these changes make the `GET api/v2/plans` ~4x faster.
- Use warden.authenticate! (instead of manually storing session[:user_return_to] + explicitly redirecting to login page) - Simplify conditional logic by checking "native" path first - Replace hardcoded "/oauth/authorize/native path" string with native_oauth_authorization_path When warden.authenticate! is invoked, Warden both automatically stores the request URL in the session and reroutes the unauthenticated user to the login page. The existing session[:user_return_to] checks in ApplicationController continue to work. This reduces custom code and leverages Devise's built-in authentication handling for better maintainability. NOTE: For better alignment with Devise conventions and automatic session cleanup, we could refactor ApplicationController to use stored_location_for(resource) instead of session[:user_return_to].
4149233 to
fcbf45d
Compare
- Use start_with?(oauth_authorization_path) instead of include?('/oauth/authorize') for stricter path matching
- Use stored_location_for(:user) instead of session[:user_return_to] for automatic cleanup and explicit Devise scope usage
- OAuth flow detection is tied to session[:user_return_to], so the :user scope is explicit and correct
- Add ? suffix to predicate method name
Improves security (prevents substring matches), maintainability (uses framework APIs with explicit scope), and follows Ruby conventions.
With the exception of specific 'disallowed paths' (i.e. `new_user_session_path` for `after_sign_in_path_for` vs `new_user_session_path` and `new_user_registration_path` for `after_sign_up_path_for`, these helpers are otherwise identical. This change refactors the code so that these helpers better adhere to DRY principles. We introduce `def after_auth_path(disallowed_paths:)`. `after_sign_in_path_for` and `after_sign_up_path_for` each call `after_auth_path` with an array containing their aforementioned disallowed paths. Some small additional refactoring is also performed. `return root_path if request.referer.nil? || from_external_domain?` allows for possible early return before assigning `referer_path`. Also, repeated `referer_path.eql?(path)` statements have been replaced with a single `disallowed_paths.include?(referer_path)` check.
Amongst its changes, this commit removes `warden.authenticate!(scope: :user)`. When warden.authenticate! is invoked, the OAuth flow is preserved while the user signs in. However, our current custom implementation of ApplicationController#after_sign_in_path_for only returns `stored_location_for(resource)` for the `oauth/authorize` path. - We could further modify after_sign_in_path_for to also return `stored_location_for(resource)` for the `oauth/applications` path. However, it is simple enough for a super admin to navigate to `oauth/applications` via the admin panel.
fcbf45d to
f4ea8f5
Compare
PR for issue #3586
This issue branch uses the doorkeeper gem to implement the Authorization Code Grant Flow (ACGF) part of the v2 API.
(The Client Credentials Flow (CCF) part of the v2 API (which is what the org-admins will use) will be implemented separately in a future piece of work.)