Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

shadrix's avatar
Level 12

How and Where to store a Secured API Key (for example for Algolia)?

So I'm trying to implement this:

//example from the page
$currentUserID = 1; // Replace by the current user ID

$securedApiKey = \AlgoliaSearch\Client::generateSecuredApiKey(
  'YourSearchOnlyApiKey', // Make sure to use a search key
  [
    'filters' => 'viewable_by:'.$currentUserID
  ]
);

However, since the user is not always logged in I don't have a user id. So my guess is just to take the session id, it should work the same right?

But now I'm curious, where should I put this part of code?

My first thought was in config.services. But can it work even though I cache the config?

Should I put it somewhere else?

To fetch the key for the frontend, I'm saving it to window.App.keys

0 likes
10 replies
D9705996's avatar

I haven't tested but could you do this with the session helper

$securedApiKey = \AlgoliaSearch\Client::generateSecuredApiKey(
  'YourSearchOnlyApiKey', // Make sure to use a search key
  [
    'filters' => 'viewable_by:' . session()->getId()
  ]
);
shadrix's avatar
Level 12

@D9705996 - Sorry, the part of session()->getId() is obvious, but thank you nonetheless. How ever, where would you save the part of code? still in config/services.php?

D9705996's avatar

@SHADRIX - Reading the documentation you provided again it looks as if all the code does is pre-applies the search filters and gives you back a key that prevents the filters being removed.

The example shows that each of the records has a viewable_by key e.g.

  {
    "objectID": "myID1",
    "name": "Mobile Search UX",
    "author_name": "Bob",
    "viewable_by": [1, 2, 3]
  },

Therefore you are going to need to have something similar in your setup and your not going to be able to use a session ID or other made up value for this as it wont be in your algolia dataset.

It might be worth taking an alternate approach and using Laravel Scout as it would allow you to enforce your filtering server side e.g.

$orders = App\Order::search('Star Trek')->where('user_id', 1)->get();

You could then have much more control over what to return if a user isn't logged in.

shadrix's avatar
Level 12

@d9705996 I really appreciate your help, but I'm a bit confused right now. I'm trying to explain it a bit more what I'm doing.

I implemented Algolia Places with Vue, so I actually cannot use Laravel Scout, since I don't need my backend for this.

At this part in the documentation, Algolia writes that we should secure the api keys.

So that is why I'm here, because I'm not quite sure if the session id is enough and where to put the code.

The goal is just to read the key dynamically out

shadrix's avatar
Level 12

@d9705996 Finally we are getting closer. There are two ways how to secure the api keys. You can combine them. As you have read it's:

-restricted API Keys
-secured API Keys

However, I'm interested in secured API Keys. I want to use my backend to generate the save keys.

After the backend generates the key, I want them to be echoed out in the header.

Like:

<script>
    window.App = {!! json_encode([
       'topSecretKey' => mymagicmethod('algolia')
    ]) !!};
    </script>

So my question is, in which folder should I put this:

$securedApiKey = \AlgoliaSearch\Client::generateSecuredApiKey(
  'YourSearchOnlyApiKey', // Make sure to use a search key
  [
    'filters' => 'viewable_by:' . session()->getId()
  ]
);
D9705996's avatar

You could put your backend code in the controller that returns the view with mymagicmethod() from your reply You can then return the generated token with the view.

return view('your.view')->with('securedApiKey', $securedApiKey);

To be honest I'm not really following why you need to use secured api keys over restricted api keys as i cant see any benefits but I'm now algolia expert. You will probably need to tweak the backend code from the documented example to get this to work properly

shadrix's avatar
Level 12

@d9705996 Because restricted API keys can be easily attacked if you know how. I just quote from here:

The referrer is an HTTP header that is sent by browsers. Like all HTTP headers, it can be spoofed, so you should not rely on it to secure your data.

So that is why you should do backend and combine it with restricted api.

D9705996's avatar

@shadrix - I would definitely look into secure API keys if the data I was using was sensitive and I couldn't lock down in my backend but in your use case you are doing Address Lookups so IMHO restricted API keys that are locked to your referrer header (even if it can be spoofed) and appropriate rate limiting (based on your expected usage) would be acceptable, certainly as my first option.

If you do want to use secured API keys I am really not sure what you are going to be able to use to set the restrictions. Possibly validUntil

1 like
dts's avatar

@d9705996 Did you ever come up with a solution to this? I am running into the same problem! Could really use a pointer.

Please or to participate in this conversation.