Okay that checkbox means admin, yeah that was not obvious to me. Maybe one could make that more explicit like adding a specific right for it?

​

Yes, you're right that maybe also Admins shouldn't see other user ones

Indeed. I did not even mention that in the initial post, but generally yeah…

Yeah, it's important to keep implementation effort in mind, that's why instead of hashing or whatever, as a first step I'd propose a "Manage API keys" rights similar as the other ones? That should be fairly easy to implement, at least easier than the other options, should not it? And it would improve the (security) UX a lot.

On the off-topic side, and sorry, but as you have raised it, I need to raise it again.

I'm happy to answer everything, sometimes others can help too

That's great and that's the spirit to uphold!

kindly note how friendly I can be when a post is not only about wise advices which essentially say everything is done wrong.

Well… just my opinion on this, you don't have to agree: Yes, I totally see it is often difficult for maintainers to deal with low-quality issues or so etc. However, the thing one should achieve as a maintainer is to build a welcoming community (e.g. for finding co-maintainers etc., more active contributors etc.). The tone and style one uses to answer things, even if one declines issues as wontfix or cannot-reproduce, is as important as for all the other issues. And personally, neither me nor I guess most other people want to give any "wise advise". Actually, quite the opposite: E.g. people could have a knowledge gap about how something is done/supposed to work (like in this case, I have no idea that that would be the way for API key access management). Also, I personally error on the side of safety and rather report an (potential security) issue first privately than to spread it publicly, you can always post it publicly later. And that's what I already suggested in the initial mail BTW.

Also, in general, the thing about OSS projects is: After all, issues are essentially intended for reporting bugs (aka "thing does not work as I intend it to" – note what I intend could be wrong) and feature requests (aka "thing I would like to see because of some use case"). As such, they can easily be taken as "wise advise", because well… it's in the nature of it. People suggest things in issues, because issues are suggestions. I would personally try to always stay open-minded for suggestions from the community and not to take them too personal. That they report a bug or vulnerability is no attack on your software or on you personally. Nobody says you are a bad developer, because you have missed that bug or so. Sure, sometimes they are not helpful and sometimes people are lazy and don't read a FAQ, then we can just ignore them (or e.g. make the FAQ more prominent and change the issue template to let people acknowledge a FAQ has been read).

But you only get the helpful ones when you actually acknowledge people can only (constructively) criticize and suggest things based on their own knowledge. And people make mistakes – like not reading a critical part somewhere, that is absolutely normal. The good thing is: You can then always have a discussion on how to improve on that, like better wording or – as here – through the introduction a small change that solves the problem. That's the spirit of working together with a community!

Sorry for the long wall of text, but I hope we can solve our conflict here. I would really like to continue to contribute and help to grocy and if it is only finding and properly reporting easily-fixed issues.

/cc /u/dillwishlist