- How do I install and configure laravel-hashid?
- Install it with Composer using composer require elfsundae/laravel-hashid, then publish the package configuration if you need to customize defaults. Set the salt through environment-managed secrets rather than committing it to source control. No database migration or backfill is required because hashids are derived from your existing integer IDs.
- Does laravel-hashid support Eloquent route model binding?
- Yes, the package includes Eloquent route binding integration so routes can resolve models from hashid strings instead of sequential integers. This lets public URLs use non-sequential identifiers while the database keeps integer primary keys. You should still test malformed or tampered route keys to confirm they return safe 404 or 422 responses.
- Is Hashids encryption or security-grade obfuscation?
- Hashids is reversible obfuscation, not encryption. Anyone who has the salt and configuration can decode the identifiers back to integers. Do not treat hashids as a secret or as security-grade unguessable identifiers unless the salt remains server-side and the threat model only requires reducing casual enumeration.
- Can I change the salt, minimum length, or alphabet?
- Yes, salt, minimum length, and alphabet are configurable. Store the salt in environment variables or a secrets manager, not in source control. Changing the salt, alphabet, or minimum length changes generated outputs and can invalidate previously shared URLs, so plan rotation carefully.
- How are invalid or tampered hashids handled?
- Invalid identifiers should fail safely, typically with a 404 or 422 rather than an exception or stack trace. The package provides validation rules and route binding integration that help with this, but you should verify behavior in your own application. Add observability around decode failures so you can detect abuse or broken links.
- Does it work with API resources and URL generation?
- Yes, the facade and helper functions let you encode and decode hashids when building API resources and URLs. Keep encoding and decoding at the HTTP or presentation boundary rather than leaking the concern into domain logic. This makes it easier to change the identifier strategy later.
- Are hashids namespaced across models?
- Hashids are derived from integer IDs and shared configuration, so the same integer can produce the same hashid across different models unless you add a per-model prefix or separate salt. Evaluate whether cross-resource ambiguity matters for your public URLs. If it does, consider model-specific configuration or prefixes at the presentation layer.
- Which Laravel and PHP versions are supported?
- Check the package's composer.json and README for the exact Laravel and PHP constraints before installing. The technical evaluation flags Laravel-version lag and modest adoption as risks, so pin the package and underlying Hashids versions. Validate compatibility in your application's CI matrix rather than assuming support for the latest Laravel release.
- Do I need to migrate or backfill my database?
- No, you do not need a schema migration or data backfill. Hashids are generated from existing integer primary keys, so the database continues to store integers. During a transition you can optionally accept both legacy numeric IDs and new hashids at the boundary while generating only hashids.
- What are the risks and what is the exit strategy?
- The main risks are that Hashids is obfuscation rather than encryption, salt rotation invalidates shared URLs, and the package has a small maintainer surface. Wrap encode and decode behind your own application interface or adapter so you can swap to UUIDs, ULIDs, or another library if needed. Pin dependency versions, monitor Laravel compatibility, and document salt rotation and rollback before broad rollout.