As discussed in my initial review, it seems unlikely that we need
the ability to remove (or otherwise modify) namespaces again.
Therefore, it seems more consistent with other extenders to go
for a "View" extender with a "namespace" method.
Sorry for the back and forth. ;)
Refs #1891, #2134.
* Write source map without creating temp file
Less I/O, and one less place where we access the global path helpers.
* Drop useless app_path() helper
This was probably taken straight from Laravel. There is no equivalent
concept in Flarum, so this should be safe to remove.
* Deprecate global path helpers
Developers using these helpers can inject the `Paths` class instead.
* Stop storing paths as strings in container
* Avoid using path helpers from Application class
* Deprecate path helpers from Application class
* Avoid using public_path() in prerequisite check
a) The comparison was already outdated, as a different path was passed.
b) We're trying to get rid of these global helpers.
* Deprecate GetDisplayName event
* Add interface for display name driver
* Add username driver as default
* Add code to register supported drivers / used driver as singletons
* Configured User class to use new driver-based system for display names
* Add extender for adding display name driver
* Add integration test for user display name driver
* Add frontend UI for selecting display name driver
- Stop trying to implement Laravel's Application contract, which
has no value for us.
- Stop inheriting from the Container, injecting one works equally
well and does not clutter up the interfaces.
- Inject the Paths collection instead of unwrapping it again, for
better encapsulation.
This brings us one step closer toward upgrading our Laravel
components (#2055), because we no longer need to adopt the changes
to the Application contract.
This ensures that default values, date attributes and relationships are properly inherited, when we have deeper model class hierarchies.
This also adds test cases to ensure that inheritance order is honored for relationship and default attribute extender. As there's no way to remove date attributes, the order of evaluation there doesn't matter.
Only users that have the new `viewHiddenGroups` permissions will be able to see these groups.
You might want this when you want to give certain users special permissions, but don't want to make your authorization scheme public to regular users.
Co-authored-by: luceos <daniel+github@klabbers.email>
- Inject contract, not implementation
- Do not dispatch event in test, let the core do that
- Ensure the relevant database tables are reset prior to the test
- Use correct parameter order for assertions
Refs #2097.
- Use private over protected
- Use "public" API for building requests in tests
- Add more assertions
- Formatting
- Use correct parameter order for assertions
Refs #2012.
* Made the console command system extender-friendly
* Added console extender
* Added ConsoleTestCase to integration tests
* Added integration tests for console extender
* Marked event-based console extension system as deprecated
* Moved trimming command output of whitespace into superclass
* Renamed 'add' to 'command'
* Added special processing for laravel commands
* Code style fixes
* More style fixes
* Fixed $this->container
There are two more API integration tests that explicitly add the
"Authorization" header right now:
- `Flarum\Tests\integration\api\authentication\WithApiKeyTest`
- `Flarum\Tests\integration\api\csrf_protection\RequireCsrfTokenTest`
These two specifically test authentication, so in those cases the
explicitness seems desirable.
I feel this makes the parameters a bit more clear, does not rely on
inheritance (you can only inherit from one class, but we might want more
of these helpers in the future), and has less side effects (e.g. no
creation and, more importantly, deletion of users in the database).
Refs #2052.
Test the request, not a controller (implementation detail). This also
focuses on the observable behavior instead of hacking our way into the
middleware pipeline in order to observe internal behavior.
The authenticated user is now determined by looking at the API response
to compare permissions and (non-)existing JSON keys.
We decided it is better to have a less intelligent search (that does not
match search terms in titles) for some people than a bad-performing
search for everyone.
We will revisit the search performance topic in the next release cycle,
possibly with larger changes around indexing.
Refs #1738, #1741, #1764.
- Extract a method for email address generation
- Consistent types
- No docblocks for types where superfluous
- Tweak console output
- Don't inherit from integration test's base class in unit test
- Fix base url when is appended with a script filename
- Add default base url http://flarum.local when CLI wizard used
- Remove some code duplication
- Add minor improvement to the UX when CLI wizard used
- Add tests
- Extract base url normalisation into its own value object
In flarum/core#1854, I changed the implementation of `assertCan()` to be
more aware of the user's log-in status. I came across this when unifying
our API's response status code when actors are not authenticated or not
authorized to do something.
@luceos rightfully had to tweak this again in ea84fc4, because the
behavior changed for one of the few API endpoints that checked for a
permission that even guests can have.
It turns out having this complex behavior in `assertCan()` is quite
misleading, because the name suggests a simple permission check and
nothing more.
Where we actually want to differ between HTTP 401 and 403, we can do
this using two method calls, and enforce it with our tests.
If this turns out to be problematic or extremely common, we can revisit
this and introduce a method with a different, better name in the future.
This commit restores the method's behavior in the last release, so we
also avoid another breaking change for extensions.
This test would have failed without commit ea84fc4. Next, I will revert
that commit and most of my PR #1854, so we need this test to ensure the
API continues to behave as desired.
This fixes a regression from #1843 and #1854. Now, the frontend again
shows the proper "Incorrect login details" message instead of "You
do not have permission to do that".
HTTP 401 should be used when logging in (i.e. authenticating) would make
a difference; HTTP 403 is reserved for requests that fail because the
already authenticated user is not authorized (i.e. lacking permissions)
to do something.
* Integration tests: Memoize request handler as well
This is useful to send HTTP requests (or their PSR-7 equivalents)
through the entire application's middleware stack (instead of
talking to specific controllers, which should be considered
implementation detail).
* Add tests for CSRF token check
* Integration tests: Configure vendor path
Now that this is possible, make the easy change...
* Implement middleware for CSRF token verification
This fixes a rather large oversight in Flarum's codebase, which was that
we had no explicit CSRF protection using the traditional token approach.
The JS frontend was actually sending these tokens, but the backend did
not require them.
* Accept CSRF token in request body as well
* Refactor tests to shorten HTTP requests
Multiple tests now provide JSON request bodies, and others copy cookies
from previous responses, so let's provide convenient helpers for these.
* Fixed issue with tmp/storage/views not existing, this caused tmpname to notice.
Fixed csrf test that assumed an access token allows application access, which is actually api token.
Improved return type hinting in the StartSession middleware
* Using a different setting key now, so that it won't break tests whenever you re-run them once smtp is set.
Fixed, badly, the test to create users etc caused by the prepareDatabase flushing all settings by default.
* added custom view, now needs translation
This creates a dedicated test suite for integration tests. All of them
can be run independently, and there is no order dependency - previously,
all integration tests needed the installer test to run first, and they
would fail if installation failed.
Now, the developer will have to set up a Flarum database to be used by
these tests. A setup script to make this simple will be added in the
next commit.
Small tradeoff: the installer is NOT tested in our test suite anymore,
only implicitly through the setup script. If we decide that this is a
problem, we can still set up separate, dedicated installer tests which
should probably test the web installer.
We are still testing the installation logic, but not testing the
actual CLI task. I would love to do that, but IMO we first need to
find a way to do this fully from the outside, by invoking and
talking to the installer through the shell.
Because acceptance tests are easier to do when fully decoupled from
the application. (After all, they are intended to save us from
breaking things when changing code; and we cannot prove that when
we change the tests at the same time.)
It might be easier to start with acceptance tests for the web
installer, though.
* fixed not being able to use master token because id column no longer holds key
* added flexibility of user_id column
* added tests to confirm the api keys actually work as intended
This lets us register the former during installation, where the
latter is not yet registered.
That, in turn, means we can finally re-enable the StartSession
middleware in the installer app, which we need to log in the new
admin user when installation is complete.
* added CreatePostControllerTest
* added DeleteDiscussionControllerTest
* added ListDiscussionControllerTest
* added TokenControllerTest
* minor improvement to policy, no need for Carbon object there, added ShowDiscussionControllerTest
* added showDiscussionControllerTest but cant make Guests view the discussion created by a user
* viewing for guests tested, we might need factories
* part one of adding tests, updating core
* Apply fixes from StyleCI
[ci skip] [skip ci]
* we need xdebug for code coverage, and hhvm was already removed
* forgot about the sidecar for mysql completely 🤦
* gitignore removed this installed json we need to fake that we have extensions
* using reguarded closure
This seems to be pretty standard. Can just run `vendor/bin/phpunit` without any arguments. Removes the need for `composer test` (which is not ideal anyway as it removes colours from the output).
