4 ms·

Hmm. I have hard-coded superusers for an app that are based on email address (where email is the login username). I'd love to hear from the HN experts if that i

by mercer 6y ago

Hmm. I have hard-coded superusers for an app that are based on email address (where email is the login username). I'd love to hear from the HN experts if that is a very bad idea and how to do it better. (initially I had a 'superuser' permission that would sort of short-circuit the permission system, but I felt really uncomfortably about how much that affected my code. I figured having compile-time hard-coded superusers per-app-instance would make more sense).

rtlfe 6y ago
> I'd love to hear from the HN experts if that is a very bad idea Yes > and how to do it better. Put these users/passwords in the database like all the other users so that you can shut them down when the passwords leak to the public.
- bzb3 6y ago
  You can also shut the user down by removing the backdoor in the code.
  - rtlfe 6y ago
    To do it via code, you have to write the code change, run it to make sure you didn't break anything, get the code reviewed, wait for it to compile, and then deploy. In database, you run one simple query.
- mercer 6y ago
  They are in the database and need to be added as users the regular way. It's just 'marking' them as superadmins that is done through a config file.
  - boring_twenties 6y ago
    I don't understand, why not just add a column to the database with the permissions?
jarym 6y ago
I think its a bad idea to hard-code anything like that. If you have to do it then accept it as a command-line argument or read it from a config file - at least then it can be backed-out with an application restart instead of a recompile.
- jarym 6y ago
  Oh and it also becomes more obvious for people who may not have access to the source code that its there!
- mercer 6y ago
  Good point. I do actually have it in a config file, so hard-coded was the wrong word to use.
fmntf 6y ago
If the application behind the login contains personal data, it's even non GDPR compliant.
- mercer 6y ago
  How so?
AdrianB1 6y ago
Never did that, but some of my apps that don't require strong security have a line in the configuration file that tells if it's in prod mode or debug mode and if it's in debug mode what user to emulate after a real, successful login. That debug config file is not checked in Git, so it never gets in places I don't want it. This way I do have to login, but I don't mess with test accounts or other people's passwords.

by mercer 6y ago

rtlfe 6y ago

> I'd love to hear from the HN experts if that is a very bad idea Yes > and how to do it better. Put these users/passwords in the database like all the other users so that you can shut them down when the passwords leak to the public.

bzb3 6y ago
You can also shut the user down by removing the backdoor in the code.
- rtlfe 6y ago
  To do it via code, you have to write the code change, run it to make sure you didn't break anything, get the code reviewed, wait for it to compile, and then deploy. In database, you run one simple query.
mercer 6y ago
They are in the database and need to be added as users the regular way. It's just 'marking' them as superadmins that is done through a config file.
- boring_twenties 6y ago
  I don't understand, why not just add a column to the database with the permissions?

jarym 6y ago

I think its a bad idea to hard-code anything like that. If you have to do it then accept it as a command-line argument or read it from a config file - at least then it can be backed-out with an application restart instead of a recompile.

jarym 6y ago
Oh and it also becomes more obvious for people who may not have access to the source code that its there!
mercer 6y ago
Good point. I do actually have it in a config file, so hard-coded was the wrong word to use.

fmntf 6y ago

If the application behind the login contains personal data, it's even non GDPR compliant.

mercer 6y ago
How so?

AdrianB1 6y ago

Never did that, but some of my apps that don't require strong security have a line in the configuration file that tells if it's in prod mode or debug mode and if it's in debug mode what user to emulate after a real, successful login. That debug config file is not checked in Git, so it never gets in places I don't want it. This way I do have to login, but I don't mess with test accounts or other people's passwords.