<@U01NZ4D0LDD> <@U01PL2YSG8L> getting this below ...
# community-help
r
@Jason Bosco @Kishore Nallan getting this below error while running scraper , we have checked we are passing the same api key for both typesense and docsearch-scraper . but still getting this error. Is there any word specific filter for api-key like
'[','*', '@' , '%'
?
message has been deleted
Copy code
self.typesense_client = typesense.Client({
            'api_key': 'xyz',
            'nodes': [{
                'host': 'typesense.test.svc.cluster.local',
                'port': 8080,
                'protocol': 'http'
            }],
            'connection_timeout_seconds': 2
        })
j
The API key should allow any type of characters
r
then why I am getting this error ? I checked with xyz api key also , but still getting same error . can you please help me out
j
Could you share the full docker command you’ve used to start Typesense?
r
sure
Copy code
./typesense-server --data-dir=$(pwd)/typesense-data --api-key=xyz --enable-cors
this is my commend from run.sh file to run typesense
and this is how I passed api key in docsearch
Copy code
self.typesense_client = typesense.Client({
            'api_key': 'xyz',
            'nodes': [{
                'host': 'typesense.test.svc.cluster.local',
                'port': 8080,
                'protocol': 'http'
            }]
        })
j
I suspect that
typesense.test.svc.cluster.local
is not pointing to the same Typesense server as that run command
Or may be something is filtering out headers before it reaches Typesense
r
the host is not public , the typesense server of us is not public link , it allows only in VPN
j
Because the run command you shared will use default Typesense port 8108, but in your client config you’re using port 8080
I’m pretty sure this is not a bug in Typesense (since we run the same binaries in Typesense Cloud for eg), and something unique about the way you’re running Typesense behind a proxy. So it’s hard to help debug what’s happening since I don’t have context into your infrastructure
r
so it not only the cause of api_key it can be cause of wrong port or wrong host ?
j
Correct
r
I know you have a very busy schedule , but we have a meeting on Friday , so that I can give me some context if this error are still getting till friday .
j
tbh, I think you might get more value from speaking to your infrastructure team. Because from the Typesense side there’s little I could do to help debug infra issues on your side.
👍 1
r
but we see that we don't pass any x-typesense-api-key on docsearch scraper , we only pass api-key which is given for typesense . so is x-typesense-api-key and typesense-api-key both are same ?
j
x-typesense-api-key
is the name of the HTTP header that gets sent in the HTTP request. But in the Python client, the parameter is just called
api_key
r
so , we don't need to pass any extra header , passing api-key inside docsearch-scraper is enough ?
j
Correct
r
ok , I will do a chat to my infra team to use same port 8108 for typesense , and we also have to pass 8108 from our docsearch-scraper
j
The actual port doesn’t matter - you’d just need to make sure the request properly makes its way to the correct Typesense instance.
I would recommend not considering this as a work request to your infra team, instead ask them for help to debug this collaboratively, because there might be some other issues lurking that might be unique to your setup
r
ok , so the issue is here what ever headers (host,port,protocol) we passed in docsearch-scraper is not referring the same typesense server which we are deployed ?
j
That’s my guess with the little I know
Or may be there’s a different API key that your production Typesense instance is using
because usually credentials are not hard-coded in a prod setting, and fetched from a vault
r
but what ever api-key we passed here this api-key will used in our typesense server na
Copy code
./typesense-server --data-dir=$(pwd)/typesense-data --api-key=xyz --enable-cors
so, is in this code typesense server api-key is xyz?
j
Correct
For eg, may be that’s not the actual command that the prod Typesense instance is running
r
so you want to say is it not the right commend to run typesense for prod ?
beacuse there don't have any chance typesense can run from different commend , we did't mention anything else in our code
let me talk to my infra team what they are said . your point is that we have to pass correct credential such that it can refer correct typesense server ?
j
All of those were just helpful starting points to dig into what the actual issue might be
I can’t tell for sure what the issue might be
From Typesense’s perspective, you run the above command with
--api-key=something
and
something
is your API key
r
ok, will cross check again
is typesense support http protocol ?
k
Yes http by default.
https
when you add ssl cert options.
r
how long a typesense search only key is Valid
k
It inherits the expiry time of the parent key.
r
I create an search only api with our parent key , and our parent key validation is lifetime until we didn't change , but our search only key's validation failed , we cant see hits using the search only api key after some time . but we are able to see hits using parent key
k
Scoped API keys don't have any expiry. Check the Typesense logs to see if any error is logged.
Wait, I think I was a bit confused. I was taking about scoped API keys earlier. All server side created keys can have expiry time as set during key creation (default is no expiry).
When you create scoped API key which is client generated, you create it from a parent key and so it inherits the expiry of parent key.
r
i am used this curl for scoped api key
curl '<http://localhost:8108/keys>' -X POST -H "X-TYPESENSE-API-KEY: ${TYPESENSE_API_KEY}" \
-H 'Content-Type: application/json' \
-d '{"description":"Search-only companies key.","actions": ["documents:search"], "collections": ["companies"]}'
and for typesense_api_key don't set any expiry
k
Yeah so that won't have any expiry. Check the logs to see if any errors are logged.
Also you can hit the /keys end-point to see if the key is still present.
r
ok
will check , thanks
if I create another scoped API key , is the previous one still validate ?
k
What you are creating is not a scoped api key. If you use the api it's a regular server side key
r
so is this not the right curl for creating an API key which allows only search operation?
k
It is but it's not called scoped api key. Those are client side generated keys
r
ok got it . so my question is if I created another key from the given curl is the previous api key also valid ?
k
Yes you can create as many keys as you want.
👍 1