3 ms·
True and if this API handled user data or anything substantially private that would be a HUGE deal and super dangerous. But it seems like in this case it's mos
by KeepFlying 5y ago
True and if this API handled user data or anything substantially private that would be a HUGE deal and super dangerous.
But it seems like in this case it's mostly a rate limiting and identification exercise and not a secure protection of user data so the impact of exposure is substantially lower. So it does seem reasonable here.
Though I hope that OP has documented all over the place "do as I say not as I do" so people don't copy this pattern.
- 256DEV 5y agodmlittle's concern is a valid one and for most other types of API I would definitely agree it's not the right approach. I still think it's reasonable for my use case but perhaps I should add another auth scheme as an optional alternative for the user who is concerned about their key potentially being caught in logs. Your point about the documentation is also a good one - I should probably add a specific page just about the authentication approach. Added to the to-do list! Thanks.
- dmlittle 5y agoFWIW you can add HTTP Basic Auth information in URL links and all major browsers and other HTTP clients (for the most part) should interpret it correctly. https://:[API_KEY]@v6.exchangerate-api.com/v6/latest/USD https://:[API_KEY]@v6.exchangerate-api.com/v6/latest/USD If you only have an API key and not a token (username) and secret (password) I recommend passing the API key as a password as some logging solutions do log the basic auth username in the data recorded.