Download the PHP package tonka/spark without Composer
On this page you can find all versions of the php package tonka/spark. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Package spark
Short Description Tonka Spark is a PHP library that provides Ziggy-like functionality for Laravel applications, allowing you to generate URLs to named routes in your JavaScript code.
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package spark
Tonka/Spark đŠī¸
The secure bridge between your Tonka Framework backend and your frontend router.
Spark is the server-side package responsible for exposing, filtering, and formatting your named routes for the tonka-router package. It features dynamic access control through Policies, allowing you to hide sensitive routes from unauthorized users effortlessly.
đ Why use Spark?
Exposing all your backend routes to the browser is a security risk. Spark solves this by giving you fine-grained control over what is visible to the frontend, leveraging your existing Policy classes to determine visibility based on the current user's role.
⨠Features
- đĄī¸ Dynamic Access Control: Integrate with your existing Policy classes to show/hide routes (e.g., hide
admin.*from regular users) automatically. - đĻ JSON Output: Generates a structured JSON object ready for JavaScript consumption.
- đĨī¸ Template Directive: Injects routes directly into your HTML (via a
data-routesattribute or global variable). - đ Groups: Organize your routes by group (e.g.,
public,auth) and expose them selectively for better performance. - đ Flexible Filtering: Use Whitelist (
only) or Blacklist (except) modes with wildcard support.
âī¸ Configuration
Publish the configuration file:
This will create config/spark.php:
đ§ Groups vs. Policies: Why Use Both?
You might wonder: "If Policies handle security, are Groups necessary?"
The short answer is yes. They serve distinct but complementary purposes:
- Policies (The "Who am I?"): Handle Security. They determine if the current user is authorized to see a specific route (e.g., hiding
admin.*from regular users). - Groups (The "Where am I?"): Handle Context & Performance. They determine which routes are relevant to the current page (e.g., only sending auth routes to the Dashboard page, not the Login page).
Why combine them?
- Performance: Without groups, sending all authorized routes (which could be hundreds) to a simple login page is wasteful. Using groups keeps the JSON payload small and fast.
- Maintainability: Groups allow you to update route lists in one place (
config/spark.php) instead of hardcoding arrays in every Blade file.
đ Usage
1. Injection in Views (Recommended)
Use the @routes directive in your main layout.
How it works with Policies:
When the page loads, Spark iterates through your configuration. For every route matching your rules, it checks the associated Policy.
- If the Policy authorizes the request â The route is included in the JSON.
- If the Policy denies the request â The route is excluded.
- If no Policy is defined â The route is included (default behavior).
2. File Generation
Generate a static routes file for SPAs:
This creates a routes.json file reflecting the current user's permissions.
3. API Endpoint
For dynamic fetching:
đ Security Best Practices
- Use Policies for Sensitive Routes: Do not rely solely on frontend hiding. Use the
policykey to ensure backend logic prevents unauthorized routes from ever reaching the browser. - Avoid
exceptif possible: Whitelisting (only) is generally safer than blacklisting (except) for API exposure. - Validate Policy Methods: Ensure your Policy classes have a public
authorize()method that returns a boolean.
đ Integration with Tonka Router
Once exposed, your frontend consumes the routes seamlessly:
