You need to register for the users that will run the server. For example, in your development machine, probably you only need to enable it for the current user, as you are going to run under your Windows user, while you are developing it.
If and when you deploy the application to another server, that app will also run under a user. If you make the app a Windows Service app, then it will be run as a service under a specific Windows user, it depends on how you configure the service to run. If it's under network service, or system user, etc,. you just reserve that URL for the Windows user running the app.
They are not related.
DefaultEntitySetPermissions
and EntitySetPermissions
are related to Aurelius CRUD endpoints. It's a high-level, automatic way to create CRUD endpoints in XData without having to explicitly code each of them. By just adding an Aurelius entity to your application, you can have CRUD endpoints being published for those entities.
By default, no CRUD endpoints are published, even when you add entities to the app. You control that by using EntitySetPermissions
- for each entity (Customer, Country, Invoice, etc.) you can define which CRUD operations you want to be published. You might want to publish endpoints GET (select), POST (insert), PUT (update) for Customer, but no Delete. You might want to publish only GET for Invoice, etc.
The DefaultEntitySetPermissions
is just a general property where you set such things for all entities at once.
Think of EntitySetPermissions
as a "development phase", i.e., which endpoints you want to be made available by Aurelius.
Now, ForbidAnonymousAccess
is about authentication and authorization, and it's at JWT Middleware level and it applies to the whole XData server - ALL endpoints, either Aurelius CRUD endpoints you published, or service operations.
The JWT middleware checks if the request has a JWT or not. If it does NOT has a JWT, then the request is anonymous (not authenticated). ForbidAnonymousAccess
controls whether you want to allow non-authenticated requests to be passed forward or not.
If ForbidAnonymousAccess
is true
, then any request that doesn't have a JWT will be immediately rejected and returned to the client with a 401 error. If it's false
, then the request will pass the JWT middleware and be moved forward in the pipeline. It doesn't mean it will be immediately accepted - it will then depend on other configurations and settings for the endpoint. It simply means the JWT middleware won't reject it.
It just increases security. This is from OAuth standard: https://blog.postman.com/what-is-pkce/
Yes, if you want to add custom claims. There are already some basic claims in the JWT, like the user id, expiration date, etc.
Correct. Almost correct, as "sign" and "encrypt" are different things. The JWT is signed with private key (not encrypted). Then the signature is verified using the public key.
Because Sphinx does it under the hood.
Because the JWT middleware is used to verify a JWT signature, to accept or reject a request based on the existing JWT it carries or not. It's used to protect a server from anonymous and/or unauthorized access. That's for your API (XDataServer), not for Sphinx. Sphinx is a public, anonymous server, you don't want to have a JWT middleware in it, it's the server that is going to give you a JWT, not to require you have a JWT to access it.
Yes.
I didn't understand this question.
I still can't compile your Client_VCL application, it still uses 3rd-party components.
After manually deleting and removing and any reference to them, if I run the Client_VCL without Sphinx server running and I client the "Log in" button I get this:
Which is expected, as the client couldn't find the Sphinx server, thus couldn't retrieve the authorization endpoint from the .well-known
endpoint.