tangui
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 !
Where Next?
Trending in Announcing
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
At WyeWorks, we believe great software is built by combining technical excellence with genuine human connection
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
**Building the future of software with AI, trust, and human connection.**
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
maz
Alright I’m going to say it: your library is a great idea but not so sure about the name. Whenever I look at it I think “API Sex” and quite possibly reminds me of a scene from the movie “A.I.”
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
csisnett
or APImate xd I coudn’t concentrate on the code if I saw the word sex so many times haha
factoryd
I don’t know. I quite like the name.
tmbb
All slightly incompatible because of mutational drift, of course.
samgranieri
I’d probably rename this…
PragTob
Hi there,
thanks for creating an OSS library sharing it with everyone!
As many others said I’d be happy about a rename of the project. It’s a level of name where I’d be uncomfortable having it anywhere in my dependencies.
lpil
Yes, I think I would be a little uncomfortable trying to talk about this library in a serious business meeting with a client or colleague.
martin
Hmm, I think those APIs should probably use some protection.
…now if only there was a package for that…