signed url for calendar feed?

so I was thinking the signed url would be a good way to offer a feed.

But the format is a bit ugly AND long (people actual have to see these to grab and paste into their cal app)...

myRadSite.com/ical-events?user=1&signature=0181b4ddda ... 370f2fd8802d

so I wrote a redirect as a first pass to consider a new way to present it...

myRadSite.com/schedules/feed/1/0181b4ddda ... 370f2fd8802d.ics

Route::get('schedules/feed/{id}/{signature}', fn($id, $signature) => 
   to_route('ical', [
	  'user' => $id,  'signature' => Str::of($signature)->beforeLast('.ics') 
   ])
)

But this is beginning to feel a bit mashed up. And the signature is long.

0181b4ddda3341449c9cce994857d9b6f91df532cdbd92d9808d370f2fd8802d

Looking for ideas on a more elegant way to offer up a feed url.

How would you do it? Signed or hash or ??

myRadSite.com/schedules/feed/{account}/{user}/0181b4ddda370f2fd8802d.ics

aidil

3 years ago

Best Answer

Level 1

There are a few different ways you could approach this problem, depending on your specific use case and requirements. Here are a few ideas:

Use a shorter, more opaque signature or hash. You could use a library or algorithm to generate a short, unique identifier that can be used to verify the authenticity of the request. This would make the URL more visually pleasing and easier to share.
Use a query string parameter instead of including the signature or hash in the URL path. This would make the URL look cleaner, but could make it less easy to share.
Use JWT instead of signature. In this case, the token would contain the signature and the expiration date, which could be much more secure and more friendly to share.
Provide a way for users to create a custom or vanity URL. This could make the URLs more memorable and easier to share, but would require some additional work on your end to handle the mapping of custom URLs to the actual feed URL.

Ultimately, the best approach depends on your specific use case and requirements. Consider the security, readability and sharability of URL when making the decision.

You can also consider combination of above methods as well.

webrobert

3 years ago

Level 51

Ok, I found laravel-hashslug. I made a mashup of two slugs, one for the tenant and one for the user.

Then the mashup can be applied to different routes.

/{tenant}/my/schedules/feed/3V8dwJlD7r0ebRjpAGEoknNg.ics
/{tenant}/reports/schedules/upcoming/feed/3V8dwJlD7r0ebRjpAGEoknNg.ics

Route::middleware('hashslug')
    ->get('{tenant:id}/my/schedules/feed/{hashMash}', ICalController::class)
    ->name('ical');

And then a middleware to check... the tenant matches the route tenant, the user hash matches a user, and the user belongs to the tenant . Overkill, or not? This makes a signed tenant + user url, right?

[$tenantHash, $userHash] = str_split($request->route()->hashMash, 12);

$tenant = Tenant::findBySlugOrFail($tenantHash);
$user = User::findBySlugOrFail($userHash);

abort_if(
    $tenant->id != $request->route()->tenant
    && ! $tenant->users->contains($user),
    404
);

return $next($request);

Please or to participate in this conversation.