I have a question about API authentication. I noticed there is a Cookie in the heather of the API call from the web interface to the backend server but I can call the server from the postman with the same API call and no headers. Does anyone know what that header is for and is there any way to secure the API call? I'm planning to deploy prodigy as a web app as most of our team are working from home now. I can add an authentication layer to the web app to secure the login. I also can add the whole thing to a virtual network to secure the access further. But it still feels weird that the API calls are not secured. I don't need the token to access the server although the token is there. Is this a bug?
Hi! The cookie in the header is currently internals only and Prodigy leaves the serving and authentication of the app up to you. If all you need is basic auth, you can enable that by setting the PRODIGY_BASIC_AUTH_USER and PRODIGY_BASIC_AUTH_PASS environment variables: Installation & Setup · Prodigy · An annotation tool for AI, Machine Learning & NLP
Alternatively, you can also use your own solution, e.g. by putting a proxy in front of Prodigy:
Hi Ines. My concern is not authentication. As I mentioned in the original post, I can add an authentication layer to secure the web app. My concern is the API that connects to the prodigy server. My understanding is that the web interface is connected to the prodigy server through an API. Say I deploy prodigy as a web app in Azure and my web app URL is https://myprodigyinstance.azurewebsites.net/. Then anyone in the world can access the API knowing this URL! In fact, I just tested it and I can do POST requests by using https://myprodigyinstance.azurewebsites.net/get_session_questions and no headers!
I inspected the source code and couldn't figure out what bearer token is used for. My initial guess was that it is used for securing the connection between the web interface and backend server but apparently I was wrong. The API call is not secured at all.
Yes, that's correct – the front-end and back-end are served together and if you just deploy the server on the public web, it's going to be accessible by anyone. So this is typically something you'd restrict and implement at the server level.
Thanks for confirming. I guess my best bet is to make a virtual net in Azure and add the web app to it so it is not accessible to the public. That would add an extra layer of security. Thanks again for being super responsive 