ltning on Nostr: nprofile1q…c5dfd nprofile1q…grlcf Ah! Well, be explicit about the various ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqrtctt2x068h9pej9repaxxwuyfgu6vwrxu77uddruee43v87wpxqwc5dfd (nprofile…5dfd) nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqkgrg8dpp6fy9y4muanwses6yw5rn75xqmn284l8dlkuctk2l5kxsrgrlcf (nprofile…rlcf) Ah! Well, be explicit about the various endpoints you expose, so you can do stuff like rate limiting and perhaps even request validity checks before anything reaches your application.
For example, have your application return some kind of session key in its initial responses, and have the client echo those in their subsequent requests. Then you can have your TLS proxy - nginx for example - keep track of these and make sure people can't submit requests with invalid, missing or expired session keys. As long as the initial and subsequent client requests come in on different paths, you can treat them separately in your TLS proxy and apply different rules for each.
Just off the top of my head :)
For example, have your application return some kind of session key in its initial responses, and have the client echo those in their subsequent requests. Then you can have your TLS proxy - nginx for example - keep track of these and make sure people can't submit requests with invalid, missing or expired session keys. As long as the initial and subsequent client requests come in on different paths, you can treat them separately in your TLS proxy and apply different rules for each.
Just off the top of my head :)