"You cannot deauthorize app" about al-objid

[vjekob]

That is what I meant :) yes! And I understand now the reason :) My only problem is, that I only testet the authorization and did not know (my fault) that the file is realy, realy important and deleted it :/ I that I will not be the only person who will do this fault , I guess. Are there any ways to fix that? Or (not important currently) to get a way for us user to fix that? :)

That's why the file contains this comment as well:

{
    //This is the authorization key for all back-end communication. Do not modify or delete this value!
    "authKey": "..."
}

I totally understand the problem, but I'd also like to hear your opinion on how would you design a solution for this? Keep in mind, authorization is there to prevent people from tampering with your ID ranges, so if you want to recover from a lost authorization key, you must have in mind that it must ONLY be possible for YOU to safely deauthorize the app, but not for anyone else pretending to be you.

I know 😉

What I am going to do about this file are these things:

1. Before you authorize, I'll ask you if you are darned sure because once you authorize, and then lose the key, you have a big, big, BIG problem
2. I'll only allow authorization on clean Git repo, meaning if you have uncommitted or staged changes, you have to take care of that first
3. After authorization key is generated, I'll create a commit for you automatically. That way at least you have some ways of getting it back if you "accidentally" lose it later.
4. Maybe, just maybe, authorization will ask you for some input. Secret, salt, whatever you want to call it. Like anything that you give the authorization process and it hashes that value together with your app ID. Then, as long as you can repeat that same input, you will be able to regenerate the authorization key.
5. Ninja will monitor the file, and if you delete the file while Ninja is running, it will warn you of the consequences and offer to recover it or something.

How does that sound? Or do you have better ideas around solving this problem?

[vjekob]

Maybe you could do some sort of Recovery Key model - like most Authenticator apps use.

One could supply an e-mail address during authorization and then you could send the Recovery Key to that e-mail address.

That would separate the recovery process from the the repository (plus you have to be extremely bored if you go through the hazzle of hacking someones e-mail, just to mess with some objects id's).

This is actually a very good idea!

I am going to store a hash of the authorizer's e-mail (I am very reluctant to store any personal details anywhere! due to GDPR) at the time of authorizing the app. When you want to recover, you have to provide the same address - and if you do, I deauthorize the app for you, and then you can re-authorize again if you want. Or something of the sort.

In any case, thanks a lot for the idea! ☺

[kaspermoerch]

Maybe you could do some sort of Recovery Key model - like most Authenticator apps use.

One could supply an e-mail address during authorization and then you could send the Recovery Key to that e-mail address.

That would separate the recovery process from the the repository (plus you have to be extremely bored if you go through the hazzle of hacking someones e-mail, just to mess with some objects id's).

[manuelgrosse]

I have exactly the same problem, we lost the .objidconfig file ( however this could happen ;) ). a fix or workaround would be great

[vjekob]

After much fumbling with different approaches, I have finally settled for the approach I explained in the earlier comment (#15 (comment)). In short, this is what Ninja now does:

• When you want to authorize, it will ask an extra question. Hopefully, people who are authorizing something for the first time in their life will stop and ask themselves "should I really do this?" before proceeding.
• There must be a git repo. You cannot authorize an app if it's not controlled by git.
• The repo must be clean. You have to either commit or stage any work before authorizing the app.
• The user is asked for one extra confirmation: the branch name on which to commit.
• After Ninja performs the authorization and generates the .objidconfig file, it immediately commits it and shows some instructions on what to do now.

Previously, I can imagine people just seeing this "authorize" and then they thought it was a good idea to authorize, whatever that meant, and then they just selected "Yes". Then at some point they noticed the .objidconfig file and wondered wherever it came from and then went on and deleted it.

Now, with all this ceremony, they can't miss it.

The process is still very simple and the only thing it requires is extra attention from the user doing the authorization, nothing more. All is still as much automated as it made sense. I could automate more, but then I would run the same risk as before: that people would go through the process without really knowing what they are doing. I don't want that.

Now, about Kasper's suggestion (#15 (comment)) - I wanted to do that, too, but I gave up. The problem is how to send e-mails from the back end for free. Without me setting up a lot of back-end infrastructure of my own, I cannot send e-mails for free. I implemented Twilio SendGrid as a proof of concept, it worked, but they only allow 100 mails per day for free. I cannot run a public service on that. You could say (and I would agree) that it's very unlikely there would be 100 apps authorized per day, but some bored "hacker" could authorize/deauthorize their app 100 times per day just to mess with the system.

On top of this authorization process, there are some post-authorization goodies:

• Ninja always shows the name and e-mail address (from Git config) of the person who authorized the app. This is shown when hovering over "Authorized" section in the status bar. Call it "Git blame" for authorization. You can now always see who authorized the app and when. I know for a fact that there were teams where somebody authorized the app, deleted the authorization file, and then played dumb and pretended they didn't do it. Now they won't be able to, anymore. When you authorize and then delete the authorization file, your team will know.
• Ninja actually monitors the .objidconfig file. If you delete it manually, it will throw an error at you immediately.

All in all, it's very difficult to "accidentally" lose the authorization file now. "Intentionally" is more likely to correctly describe losing it now.

And that's it. I don't want to make rocket science out of it. It was far less robust for the first 5 months of Ninja's life, and there were maybe 10 teams in total who had problems with this. With all this new stuff in place, I believe there will be very few of them. Ninja is not bulletproof here, but it certainly takes all the steps it can to make sure that if this problem happens ever again, it's user's fault, not Ninja's.

I am closing this issue as this will be released today or tomorrow in 2.3.0.

[vjekob]

This is by design. I am sorry for the inconvenience, I understand this must feel very bad, but let me explain (the documentation explains this as well, but let me clarify).

Authorization is needed for those apps where you want to prevent malicious tampering with your object ID consumption by third parties that know your app ID. If you are not concerned about this, then you don't need to authorize your app.

HOWEVER once you authorize your app, then the back end MUST reject any request that are not carrying valid authorization key with them. For AL Object ID Ninja to be able to send this key to the back end, it MUST read it from somewhere. That somewhere is the .objidconfig file.

Furthermore, if you are working in a multi-user repo (which you probably are, otherwise there is no need to use AL Object ID Ninja!), then for anyone (that is: any user working in the same repo) to be able to send any requests to the back end, they all must send the same authorization key.

That's why this file (.objidconfig) must be included in the repo. If you don't include this file in the repo, then AL Object ID Ninja cannot communicate with the back end.

Since you deleted the file, you have lost your key, and your AL Object ID Ninja is sending requests to the back end without the authorization key. However, since you didn't deauthorize the app first, the back end does not know that your configuration file is gone, and it rejects your request with 401 Not Authorized status.

I hope this explains the situation.

The only thing that I believe might be wrong here is the wording. You cannot deauthorize app not because it is not authorized, but because you are not sending correct authorization key. Please let me know if this is what you actually wrote about.

[aptMattKoe]

That is what I meant :) yes! And I understand now the reason :)
My only problem is, that I only testet the authorization and did not know (my fault) that the file is realy, realy important and deleted it :/ I that I will not be the only person who will do this fault , I guess.
Are there any ways to fix that? Or (not important currently) to get a way for us user to fix that? :)

[waldo1001]

But .. doesn't that kind of beat the purpose? If I can "fix" having to use the authentication key - I can hack it anytime, right?

What if you "simply" change the app-id? Would that be an option?

[aptMattKoe]

Your point is valid but in an AppSource App with Apps that depends on that? :/

[vjekob]

Right now, the workaround is for anyone who has a legitimate app in development (meaning: not some test "AL: Go!" type of sandbox where you played around with Ninja just to see how it works), and you "somehow" lost the .objidconfig file, you just write to me with the App ID and the range you used. Then I deauthorize your app manually.

[aptMattKoe]

That's why the file contains this comment as well:

jeah :/ This time I was the user who does not read very well.

All your plans sounds great!
I do not know if its easier but I thought about an timerange to deauth without the file? (could be in an cache?!) or that the obj. file will also be copied to some kind of temp folder (in case of "emergency").
I think your solutions are better :)

[kaspermoerch]

I am going to store a hash of the authorizer's e-mail (I am very reluctant to store any personal details anywhere! due to GDPR) at the time of authorizing the app. When you want to recover, you have to provide the same address - and if you do, I deauthorize the app for you, and then you can re-authorize again if you want. Or something of the sort.

I think that is a good solution.

You wouldn't have to store the e-mail. You could just fire and forget. Generate the recovery key, send it to the provided e-mail address and then throw the e-mail address away.

[aptMattKoe]

woa thats sounds like an good solution! cool!
Both ways :)
The recovery key had the benefit that I could store it into the password manager. When I'm not in the company anymore, anyone could De-Auth and Re-Auth the App so that I (what I never would do!) could not reset it so easily and annoy my ex-colleagues. But this is also an solution for the E-Mail Address :D

[BrianThorChristensen]

Right now, the workaround is for anyone who has a legitimate app in development (meaning: not some test "AL: Go!" type of sandbox where you played around with Ninja just to see how it works), and you "somehow" lost the .objidconfig file, you just write to me with the App ID and the range you used. Then I deauthorize your app manually.

I find my self in a similar situation, that I cannot deauthorize.
Maybe you could provide a preferred way to communicate with you.

[vjekob]

The best way to report this and get the fix ASAP is to contact me on LinkedIn or Twitter (direct message) and send me your app ID.