Checks when adding APIs

[PerMalmberg]

@Adarnof we've discussed this before and it was then concluded there was a bug that was later fixed.

We got a new application from a prospective member, but the API provided only included basic info, kills and character sheet and only a single character, despite the settings as follows ():

IS_CORP = 'True' == os.environ.get('AA_IS_CORP', 'True')
MEMBER_API_MASK = os.environ.get('AA_MEMBER_API_MASK', 1073741823)
MEMBER_API_ACCOUNT = 'True' == os.environ.get('AA_MEMBER_API_ACCOUNT', 'True')
BLUE_API_MASK = os.environ.get('AA_BLUE_API_MASK', 8388608)
BLUE_API_ACCOUNT = 'True' == os.environ.get('AA_BLUE_API_ACCOUNT', 'False')

I tried this myself and the system gladly accepts APIs with less than the set requirements.

Am I missing something or is has this bug resurfaced?

[ghost]

@PerMalmberg I found the same issue. When I had members refresh their API key though or if the API refresh task ran, it gladly removed those API keys that did not match requirements. I don't know if that is the case for you.

[PerMalmberg]

No, this is when they first add the API.

[Adarnof]

The validation of keys works as follows:

• a list of character states are compiled, for each character on the key plus the user's current state
• the key is then checked against requirements for each state found

What's happening is the user is not member nor blue, and the character on the key is not member nor blue, so no checks are performed.

Would you prefer if the validation defaulted to member if no states are found?

[PerMalmberg]

If I set the system to require a certain access mask, then it should not accept anything less.

And of course the user is not a member yet, s/he is about to do the application. So, we need a way to enforce all apis to the required mask prior to application creation.

[Adarnof]

Yet another reason I want to remove the blue/member distinction...

Easiest solution: Require all keys to meet the same mask.
Harder solution: Default to member requirements if not blue.

Still no idea why some keys are slipping through for members.

[orbitroom]

@Adarnof option 3 would be to validate the keys when their added and raise and exception so that it shows up on the api key form it self and then it will tell the user what their major malfunction was

[PerMalmberg]

I'm not sure how it should work when used in alliance mode, but when IS_CORP is true, the validation logic is simple: any API not matching MEMBER_API_MASK should be rejected.

Also, the text (lings to API creation etc.) for "blue" shouldn't be visible at all when IS_CORP is true.

[Nutbolt52]

I have seen this occurring a lot with my install. Its not a ground breaking bug because people should learn to read, but it does result in a lot of people being confused. Not really sure what else I can do to help though. I run AllianceAuth in Corp mode and have a minimum required API set to the max. People can register/add API key with a lower mask, it accepts it and grants them access to the appropriate services, but then on the next celery run it removes their access as it notices the API key doesn't have the right mask.

[Adarnof]

For those wondering:

This would only occur the first time a new user added a key which was not up to mask requirements. This was caused by incorrectly comparing corp/alliance IDs from models (strings) to those from settings.py (ints). This would determine non-blue characters were none, rather than members. After the key was added, a separate logic function would correctly identify the users were members/blues and apply the correct API checks during the 3-hour api refresh cycle. After adding one key, the user would be identified as the correct member/blue state so any subsequent key additions would be correctly checked.