potential plugin concepts to inform plugin system development
Stephen Crosby
Here are some ideas I’ve cooked up on possible plugins for praxis to support. Describing exactly how these could work is a topic for another discussion. I’m hoping this discussion on possible plugins will help inform the next discussion on how plugins will work.
And these are just my ideas. We can talk about these or any others that might help set the stage for what plugins should be.
I'd love to hear from you if you have an idea for a plugin that would introduce a use case or pattern not covered by these plugin ideas, especially if it could introduce a new integration point with Praxis.
role-based access control
specify some required configuration at boot time, like credentials for the backing ACL system
-
accept/access configuration values
-
extend the dsl for resource definitions with a new method along the lines of headers/routing/etc so you can specify which roles are required for each action
add some response definitions to the entire application like ‘access denied’ (and documentation for those definitions)
hook into the request lifecycle to do actual auth checks
extend the documentation with information for the user about how the access control system works. For example, "MyAuthorizationSystem is a role-based ACL system. These roles exist: blah, blah blah"
extend the documentation for resources/actions with information about which roles are required for which actions or even views
custom versioning system
implement an identical versioning system to praxis’ built-in system, with a custom header name, not because it’s super useful to make this exact plugin, but because I think interacting with the versioning system could be a useful part of plugin development
auto-handle xml (or other kinds of) request bodies as payload
hook into the request lifecycle, check to see if the request content type is my/special-type and munge it into something accessible via the payload interface
in the generated docs, add examples in xml format
etag and last-modified plugin
provide a common interface for actions to handle If-None-Match and If-Modified-Since request headers and send ETag and Last-Modified response headers
probably use some action dsl to opt action definitions in and out of using these interfaces, and add relevant documentation for which actions support which of these systems
add an example on how to use these (generically) to the user-facing documentation
-
append response headers to all the generated responses that use this interface in the docs
add a new response definition for 304 not modified for this plugin to use
request rate limiting
describe and accept configuration for the plugin
extend the dsl for api definition, resource definition, and actions to attach portions of the api to a rate limiting strategy (maybe by action, or resource, or maybe api-wide)
add user-facing documentation on how rate-limiting works
-
add a special action and maybe also a route just for this plugin to describe the current state of the rate limiter
add response headers to all/some response definitions to describe the state of rate limits
-
add a response definition for when the rate limit is exceeded
Justin Gaylor
- Move the default logging in Praxis
- Probably Logger-based
- User can configure where to spit out logs (file, network, stdout/stderr, etc) and app log level by environment
- Extract existing Praxis health-checking feature
- Provides a health-check action which takes additional params for what checks to do (mysql connectivity, memcached, etc.)
- The "what checks to do" information maps to callbacks/hooks that plugin user implements
- Also sprinkles additional info into docs regarding what checks are available
- simple plugin to inject a RUNTIME header into the response
Justin Gaylor
- A plugin which adds formats for the serialization of responses.
- These could be JSON (in current Praxis), XML, CSV, HTML, etc.
- Would support receiving a 'format' parameter.
- Plugin consumer could implement an 'Error' mediatype (or perhaps this plugin defines one?)
- Any errors returned from Praxis get packed into this mediatype instead of returned as plain text.
- Errors would include additional info such as: name, message, request uuid, subsystem, etc
Justin Gaylor
- The plugin exposes some additional API calls (available on each resource endpoint?)
- These calls return a complete description of the API's interface (resources, mediatypes, actions, params, param types, etc.)
- The calls can accept a 'format' parameter and return JSON, SOAP, swagger, or other interface standards.
Maciej Kruk
- User registration (preferably extensible enough to use with username/email/phone number/facebook/google+/any other oauth)
- Login functionality
- Multiple variants of token authentication (expiring/non-expiring/custom token verification script)
- Similar to role-based access control, but rather than constraining user to roles, let them write their own permission rules
- Rather than action-based, resource based
- A very lightweight gem for immediately returning from any place in the code
- Exceptions based
- respond(code, msg) or fail(code, msg)
Josep Blanquer
--
You received this message because you are subscribed to the Google Groups "praxis-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to praxis-developm...@googlegroups.com.
To post to this group, send email to praxis-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/praxis-development/a7f25723-2f1a-47d9-b76e-8d5d5fc1481c%40googlegroups.com.