No-no when you making modules

[supernova-ws]

First of all I want to thank for a great module! It's very cool stuff but unfortunately I can't risk to use it for now even for pet project.

As I see there are two critical no-no for open-source modules:

1. You can't store your specific secret info in global config files that would go to repo. What am I talking about?
   https://github.com/datamweb/shield-oauth/blob/develop/docs/install.md#set-keys
   By all means this file contain critical information and can be easily added into repo - by mistake or by sheer absence of experience.
   Solution? There are two of them
   1.1. Add notice to add file to .gitignore - not a perfect solution but at least inexperienced developers would be warned and educated about dangers of adding critical info into repo. Also it would remain to other developers that they should make some extra steps to secure their personal info. But there is still a problem - single key set would be used for different environments which will add some PITS in multi environment... environment.
   1.2. Use .env file. IMHO much better way. This file already in .gitignore so it will not accidentally leak to repo. Also it eliminates problem with first approach - different environment have different .env files so you can easily separate keys for dev/test/prod/CI/CD/etc. environments.

2. Changing files in vendor folder.
   https://github.com/datamweb/shield-oauth/blob/develop/docs/install.md#adding-all-login-button-with-oauth-in-view
   You offer to tamper with original CI4 package files which really could be deleted and/or changed on any moment.

Moreover - you will need to make this changes manually on any new deployment of CI4-based site! Because vendor/ folder is absolutly .gitignored and shouldn't be included in repo.

Most interesting that you personally answered on question how login view can be overwritten:
codeigniter4/shield#480

Why you don't use same approach for your module? That's really question - not a sarcasm. I'm only started to use Shield in my pet-project so I assume there some problems with this approach?

Another possible method: there is a whole chapter in documentation about overriding Shield's controllers: https://codeigniter4.github.io/shield/customization/#extending-the-controllers
So it's easy to write own controller which will use own view for login form.

I will try (no promises, however) to implement this approaches when I finish with Shield itself - because IMHO having Google auth is crucial for every site. Also GitHub and other OAuth sources would be a nice touch too.

[datamweb]

First of all I want to thank for a great module! It's very cool stuff but unfortunately I can't risk to use it for now even for pet project.

Hello @supernova-ws.
Thank you for your feedback. When I decided to release shield-oauth, I never thought it would be installed more than 3-4 times, but so far it has been installed almost 4000 times. This number of installations increased my responsibility and I was not personally ready for such a thing. Whether in terms of knowledge, expertise, or free time, so I assumed that one of the main members of the CI4 team (senior) would be with me in this resource, which unfortunately did not happen (time is valuable for everyone).

1. You can't store your specific secret info in global config files that would go to repo

I know the senior opinion of the CI4 team and it is preferable to store important information in file .env. But is there anything about this in CI4 documents? If yes, please provide a link?

1. 1.2. Use .env file. IMHO much better way. This file already in .gitignore so it will not accidentally leak to repo. Also it eliminates problem with first approach - different environment have different .env files so you can easily separate keys for dev/test/prod/CI/CD/etc. environments.

I like this solution, it is not complicated or hard to implement. shield-oauth an open source project and anyone can contribute if they wish. A sample implementation is available here.

2. Changing files in vendor folder.
https://github.com/datamweb/shield-oauth/blob/develop/docs/install.md#adding-all-login-button-with-oauth-in-view
You offer to tamper with original CI4 package files which really could be deleted and/or changed on any moment.

In this regard, I have given a warning in the documents. If you think this warning is not clear enough, please submit a PR for this issue.

Another possible method: there is a whole chapter in documentation about overriding Shield's controllers: https://codeigniter4.github.io/shield/customization/#extending-the-controllers
So it's easy to write own controller which will use own view for login form.

There is no need to do this, you can add the word {{ShieldOAuthButtonForLoginPage}} or {{ShieldOAuthButtonForRegisterPage}} in any custom shield view.

Thanks again for your feedback, I hope I answered all your questions.

[supernova-ws]

1. 1.2. Use .env file. IMHO much better way. This file already in .gitignore so it will not accidentally leak to repo. Also it eliminates problem with first approach - different environment have different .env files so you can easily separate keys for dev/test/prod/CI/CD/etc. environments.
   I like this solution, it is not complicated or hard to implement. shield-oauth an open source project and anyone can contribute if they wish. A sample implementation is available here.
   It's pretty easy to implement: https://codeigniter.com/user_guide/general/configuration.html?highlight=env#dotenv-file
   Just use $_ENV as a primary source for your configuration and only if there is no keys for your module then you can fall-back to data from App\Config folder. There are 2 caveats on different aspects:

1. Be aware that $_ENV WILL be added to your environment variables - as it intended to be BTW. There is special warning for this on CI4 page: https://codeigniter.com/user_guide/general/configuration.html?highlight=env#getting-variables , see Warning. That can be mitigated just by quoting exact info in documentation file for module. I think this is a miniscule problem because both var_dump($_ENV) and phpinfo() requires direct and consent action from developer. But a reminder for unsafe thing IMHO is always welcome.
2. About fallback. IMHO option to configure module via App\Config file should also be possible - at the end of day only developer should decide how he would like to configure his app. But to mitigate (to some degree) possible security risk I think there is should be note in module documentation about danger to commit sensitive information into repo - and that you can add file to .gitignore to prevent such heinous act to happen.

As a side note: configuration through environment - via OS variables or via .env file - is a common method to setup CI/CD/test environments like Scruthinizer/Jarvis/Hudson/etc. and other.

2. Changing files in vendor folder.
   https://github.com/datamweb/shield-oauth/blob/develop/docs/install.md#adding-all-login-button-with-oauth-in-view
   You offer to tamper with original CI4 package files which really could be deleted and/or changed on any moment.

In this regard, I have given a warning in the documents. If you think this warning is not clear enough, please submit a PR for this issue.

Warning is good but really not so useful. I think something like example would work much better.

Another possible method: there is a whole chapter in documentation about overriding Shield's controllers: https://codeigniter4.github.io/shield/customization/#extending-the-controllers
So it's easy to write own controller which will use own view for login form.

There is no need to do this, you can add the word {{ShieldOAuthButtonForLoginPage}} or {{ShieldOAuthButtonForRegisterPage}} in any custom shield view.

I'm really not sure if it's a good practice. Again - not a sarcasm. On this stage on learning CI4 I don't know what is a good practice to perform such a trick.

As idea: you already use Boostrap and there is need to include some JS code in view. My proposal is to use something like own view which will include login/register views from vendor (which is OK, because CI4 code can be updated w/o interference with actual code). And code for buttons can be placed in DOM relative to known elements of Shield's login/register elements. It can even be automated to generate ready-to-use login/register views based on Shield's views.
So it would look something like:

<?php require_once (app_path)\vendor\codeigniter4\shield\src\Views\login.php ?>
<?= $this->section('pageScripts') ?>
<script src='https://cdn.jsdelivr.net/npm/@popperjs/core@2.11.6/dist/umd/popper.min.js' integrity='sha384-oBqDVmMz9ATKxIep9tiCxS/Z9fNfEXiDAYTujMAeBAsjFuCZSmKbSSUnQlmh/jp3' crossorigin='anonymous'></script>
<script src='https://cdn.jsdelivr.net/npm/bootstrap@5.2.2/dist/js/bootstrap.min.js' integrity='sha384-IDwe1+LCz02ROU9k972gdyvl+AESN10+x7tBKgc9I5HFtuNz0wWnPclzo6p9vxnk' crossorigin='anonymous'></script>

<script>(code to generate HTML buttons and to position them, say above login form)</script>
<?= $this->endSection() ?>

Of course, those who wants advanced login/register page can design and implement their own forms with different layouts and still can use specific decorators.