Still able to join the room with the expired token

oki but how to run postman on jitsi server? i dddnt understand that part

You don’t need to use postman on the server. I was just trying to understand how you are currently testing connectivity since I keep pointing out that prosody is not able to talk to your API.

You can run something like curl from the server to test.

You have API deployed locally on the server as well, yes?

1 Like

locally running on 3000 but not deployed, i just start the and run the nest applicaiton on localhost…

if my prefix is correct then wat could be the reaosn prosdy coldnt coneect to api?

Have you tried connecting to your API locally using curl?

This will likely be down to how you are running your API server. Very hard for me to speculate.

for ur information when i commented the prefix line and restarted jitsi, room is created, but i expected

the issue is this,

Then you need to debug that. Your API is not listening on port 3000.

but i could call and talk with it using postman right?

You were using postman on a different machine and calling localhost, which means it was talking to a different server.

The one you’re running on the jitsi server is not working yet.

i checked a another url which is in deployment and it gave it response. so it can be port or ip issues, should i want to depploy it ?

I’m afraid I am not in a position to debug deployment of API you wrote.

Happy to assist once your API is accessible and you have other issues with the prosody module.

Good luck :muscle:

1 Like


hi just one more thing to clarify, if the reservation instance with all the details exist in the db, it gonna retrun the conflict_id and with that conflict_id, jitsi gonan call /conference/conflict_id api and get the get one reservation details and provide the room right?

Not really, no.

For a general use case, you API only needs to handle the following (uri paths below relative to reservations_api_prefix:

  • POST /conference
    • Called when prosody is about to create a new room
    • If you want to allow the room creation, respond with HTTP 200 and the reservation details in the body as documented
    • If you want to reject the room creation, respond with HTTP 403 (or any code other than 200, 201, 409)
  • DELETE /conference/<conflict_id>
    • Called when the room is destroyed. This could be when everyone leaves the room, or if duration expired and room is closed by prosody
    • <conflict_id> will be whatever conflict_id value returned by the API during the room creation

That should be sufficient in most cases.

All other endpoint behaviour mentioned in the docs is mainly to handle case a where you have multiple shards running, and you want to handle differently the case where one server crashes and users are redirected to a different shard and room is recreated. That’s when the HTTP 409 response and the GET /conference/<conflict_id> is applicable.


that gave me the whole pciture , thank u, we must add this in doc, :grinning_face_with_smiling_eyes:

in whcih log can we the request body with the reservatiuon detials that sent to the api?

You’ll need to log it out from you API.

thank u, reservation worked. thanks alot, @shawn

i created room and had meeting and end it, so reservation also got deleated, if i again start new room wiht the same room name , wont that work?