tangui
APIsex: API security for elixir
Hi all,
I’m releasing version 0.1.0 of APISex libraries. These are libraries for API access control.
6 plugs are ready to use:
-
APISex.Authenticator:- APISexAuthBasic: implementatoin of the Basic HTTP authentication scheme (RFC7617)
- APISexAuthBearer: implementation of the Bearer HTTP authentication scheme (RFC6750) and the OAuth 2.0 Token Introspection (RFC7662) token verification method
- APISexAuthMTLS: implementation of the OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens draft-ietf-oauth-mtls-12 RFC
-
APISex.Filter:- APISexFilterIPWhitelist: IPv4 and IPv6 address whitelisting
- APISexFilterIPBlacklist: IPv4 and IPv6 address blacklisting
- APISexFilterThrottler: throttler that can throttle on IP address, client, subject, URI, etc.
When dealing with API access control I think you have 2 cases:
- You consume your APIs from the web page javascript
- In this case using cookies for API access control does the job
- Your APIs are consumed by websites on other domains (cookies aren’t shared between different domains), third-parties (OpenAPI or information exchange with partners (machine-to-machine)) or mobile applications
- Here you cannot use cookies (except using ugly and dangerous hacks) and APISex plugs may help you use a protocol designed for that
Any comment, review, question is welcome.
Have a great weekend !
Most Liked
AstonJ
I agree about the name. Whenever releasing something that might be used by others, or those in a professional environment, it’s best to stick to clean/neutral language 
What about APIsec? 
eksperimental
What’s wrong with Sex?
It´s Sex between APIs, that’s why there are so many APIs around 
AstonJ
That’s of course your prerogative. But I’d just like to say that many of us are simply trying to build this community on (and in fact it was started with) the principle of being considerate and mature. This is reflected in the Elixir CoC and these are the sort of ideals that we strive for on the forum.
Sticking to these ideals of course also helps ensure the focus remains on the library itself rather than its name, as well as increases the chances of it being adopted and used by others - which is something I’m sure most library authors would prefer.
As the OP has stated he is going to rename the library (and is welcome to post a new thread once he’s done that) I think it’s time to close this thread. Thank you @tangui and thank you everyone who left feedback ![]()







