Laravel Trustup Io Authentification Laravel Package

Getting Started

• Install with composer require trustup-io/laravel-auth (or the specific Trustup auth package in use), then publish its config: php artisan vendor:publish and pick the Trustup auth config tag. The config file is the first place to look — it is where every service URL and credential the package consumes is defined.
• Set the environment variables the config reads. As of v4.0.1 this includes TRUSTUP_IO_AUTH_DOCKER_URL, which controls the base URL used when the package talks to a Docker-hosted auth service. The value must now include an explicit scheme, e.g. TRUSTUP_IO_AUTH_DOCKER_URL=http://auth.docker.localhost.
• First use case to validate end-to-end: run the app locally with the Docker auth container up, point TRUSTUP_IO_AUTH_DOCKER_URL at it, and exercise a single authenticated request. If that works, the Guzzle wiring, config resolution, and credentials are all correct and you can move on to real integration.
• Check composer show guzzlehttp/guzzle early. v4.0.1 exists specifically because Guzzle 7.13+ tightened how base_uri is handled, so knowing your Guzzle version tells you whether you need this patch at all.

Implementation Patterns

• Treat the config file as the contract. Resolve URLs, timeouts, and credentials through config('...') rather than constructing them inline. Every environment (local Docker, staging, production) should differ only by env vars, never by code.
• Keep the scheme explicit everywhere. The v4.0.1 change means scheme-less hostnames like auth.docker.localhost will break under Guzzle 7.13+. Make this a convention across all your Trustup-related URLs, not just the docker one, so the next Guzzle bump doesn't bite you again.
• Layer Docker overrides on top of defaults. A common pattern is a base auth URL in config plus a docker-specific override that only applies when APP_ENV=local. Keep the override additive so production config stays untouched.
• Fake the HTTP layer in tests. Use Http::fake() (or bind a fake client into the container) and override the relevant config keys per test rather than relying on .env.testing. This keeps tests independent of whether a Docker auth container is running.
• Wrap calls in your own service class. Rather than injecting the package's client directly into controllers, wrap it in a small AuthClient-style class. That gives you one place to handle retries, logging, and the URL resolution logic, and one seam to swap out if the package's API shifts in a future major.
• Use Laravel's HTTP client events for observability. Http::globalRequestMiddleware() or the RequestSending/ResponseReceived events let you log outbound auth calls without touching package internals.

Gotchas and Tips

• Config caching will hide your env changes. After editing TRUSTUP_IO_AUTH_DOCKER_URL (or any Trustup env var), run php artisan config:clear in local/dev. In production, make sure config:cache runs during deploy after env vars are in place — cached config snapshots env values at build time.
• The v4.0.1 fix is a compatibility patch, not a feature. If you were seeing Guzzle exceptions about an invalid or missing base URI, upgrading to v4.0.1 and setting the scheme explicitly in your env resolves it. If you were not seeing those errors, the upgrade is low-risk but also low-value — no new capabilities to adopt.
• Don't hardcode http:// into config defaults. Docker is http, production is almost certainly https. Default the env var to an empty/null value and let each environment supply its own fully-qualified URL, or you'll ship plaintext endpoints to production.
• Debugging URL resolution: dump config('...docker.url') (or the equivalent key) via php artisan tinker when a request fails. Nine times out of ten the failure is a missing scheme, a trailing slash inconsistency, or stale cached config — in that order.
• Extension points: the config file is the primary one. Beyond that, bind your own implementation of whichever interface the package exposes for the auth client in a service provider if you need custom headers, retry policies, or middleware.
• Watch the major version boundary. You are on a v4 line. When reading docs or Stack Overflow answers, confirm they refer to v4 — configuration key names and client wiring commonly change between majors, and a v3-era snippet will silently misconfigure you.