Secure an API endpoint but not JWT

Bubbleboy

I've read and reread the documentation and reviewed the copious tutorial videos but I'm still at a loss to one question:

Hypothetically, just suppose I have users and those users are interacting with my application to build survey forms for example. The user would login and would authenticate and access via JWT to build a simple survey form. the API endpoint for the survey form would be protected.

The user could then provide a link (URL) to that survey form for Joe public ( a non-logged in user) to fill in or complete said survey form.

My question is this, if the survey form is protected is there a method or anyway I can then access the survey form via a separate part of my application for a non-logged in user but still protect access to the API endpoint.

An example from bubble.io. I would have a logged in using JWT user but bubble.io provides a separate API endpoint ( generic if you like) which allows me to protect any database object. 

EDIT or do i simply specify "internal" for those field i do not want to expose to the api endpoint

Ray Deck

Yes, you can control any endpoint with the access level you choose. So you could say you're not using built-in Xano authentication for a specific endpoint, and that endpoint then returns whatever fields from whatever table you say are OK. There's a lot that _can_ be done. Maybe the question is more specifically what functionality you are going for in this use case? 

Bubbleboy

 thank you for the response. Hopefully this one query / scenario will explain the context and rationale of my query.  this just take the  /auth/signup . How can this be managed/protected from my application... Meaning only users who go to my application/page basically sign up. Versus someone who could theoretically make a post to my API endpoint any number of times and create users. 

Can the poster this API endpoint have a generic token that makes sense?

Ray Deck

sure! You can add any arbitrary header (like one identifying your app) to your request and have your signup endpoint look for and validate that header using a precondition. You just a few lines in your function stack at the top to handle that situation.

Of course someone might inspect traffic and figure the game out. This is not an absolute assurance, just making it more secure.

Bubbleboy

Ahh understood that makes sense...