Artisan Tinker to inject first user during install of Laravel/Composer app

wbk · March 3, 2025, 2:52pm

Hi all,

With help from the forum, my package is progressing bit by bit.

Most things work now, but one thing is causing some trouble: creating the first/single user during install.

The app is built on Laravel/Composer, Artisan Tinker provides a way to insert a user into the app via the command line. The command runs fine if I run it manually after installation, but integrating the command into the install script makes the install break at that point.

Here in an excerpt from the install log:

Info: DEBUG -   Database\Seeders\LabelsSeeder ......................................................................... RUNNING
Info: DEBUG -   Database\Seeders\LabelsSeeder ....................................................................... 5 ms DONE
Info: DEBUG -
Info: DEBUG - + php artisan tinker
Info: DEBUG - = App\Models\User {#6290
Info: DEBUG -     name: "testuser",
Info: DEBUG -     email: "testuser@domain.tld",
Info: DEBUG -     #password: "$2y$10$vkJ19Qa8.mOUbMK7Ed3kmuDgtmJFOrtrV3UbkgjLBjkniJ6LeZkOO",
Info: DEBUG -     api_token: "**********",
Info: DEBUG -     updated_at: "2025-03-03 14:36:46",
Info: DEBUG -     created_at: "2025-03-03 14:36:46",
Info: DEBUG -     id: 1,
Info: DEBUG -   }
Info: DEBUG -
Info: DEBUG - + ynh_exit_properly
Warning: Removing the app after installation failure…
Info: [++++++++++..........] > Removing system configurations related to my_idlers...
Info: [####################] > Removal of my_idlers completed

The corresponding commands in the install script are:

	"php$php_version" artisan migrate:fresh --seed -n --force
     echo "use App\Models\User; User::create(['name' => '$user', 'email' => '$email' , 'password' => bcrypt ('$password'), 'api_token' => '$token']); " | php artisan tinker
	"php$php_version" artisan config:clear -n

At first I had the echo "use App\... tinker-line under the other artisan lines; in that case config:clear runs fine and it still breaks on the tinker line after that. As you see in the log, the command gets executed, it is after immediately that that the install gets broken off.

I may be blissfully using the wrong technique to populate the database with a first user; if so, please guide me in the right direction!

As an aside, last days I pushed my changes to Github as well, but this morning Github declared my public key invalid. I haven’t looked into the cause yet. How do you guys push changes to Github?

jarod5001 · March 3, 2025, 3:24pm

May be using ynh_hide_warnings
Interesting way of creating the first user.
Does this app have a command line tool? As you may have noticed, lychee has a lot of commands that have been created by the dev.
Otherwise, is it possible to create the user from the Web interface? You can use ynh_local_curl
For pushing changes to github, I work mainly on the web interface of github and sometimes on my phone (which is a pain)…
Otherwise, I have used vscodium with git extension. It’s great.

wbk · March 3, 2025, 4:21pm

Hey, thanks!

I hadn’t heard of VSCodium before, I’ll look into it!

The app relies on the framework for interaction, which works quite nicely, but no direct command line interface.

Hiding warnings could help getting through the install, but there doesn’t seem to be a warning other than command feedback.

ynh_local_curl seems a better solution, keeping it in line with YNH tools and in line with normal use of the app.

Come to think of it, I inject the user to have the app ready to use, but while writing this, I realize that maybe it is better to let the user create the credentials by themselves at the webinterface of the app. Any password vault will have less trouble relating the credentials to the app that way.

Any suggestion on that?

In case I leave out injecting the user, the package is ready to fly the nest. It can be found at GitHub - w-b-k/my_idlers_ynh at development ; where do I take it from here?

jarod5001 · March 3, 2025, 7:12pm

Make it work then add other options.

You have to change ownership of the repo to yunohost organization. And about the branches of the repo, there are two mandatory : master and testing. You can add more in case you are trying to add things then PR to testing. Don’t forget the doc folder. Since you are letting the user register himself in the app, you can add notes in the preinstall and postinstall. Delete unnecessary files.

wbk · March 4, 2025, 4:55pm

My package is available at Github now

Most of it works, but I’m not sure how to use ynh_local_curl.

The registration page of the app is available at https://sub.domain.tld/register , my local-curl line is:

ynh_local_curl "/register" "name=$user" "email=$email" "password=$password" "password_confirmation=$password"

I looked for the field names in the source of the page; visually it looks like this:

With the location /register, the install log tells me the page was expired. I did try some other locations, those attempts ended up in SSOwat.

Any idea?

jarod5001 · March 4, 2025, 6:21pm

I have used in ojs_ynh/scripts/install at b6f4d0275c8742d32368f26bd7c035c801b7dc9d · YunoHost-Apps/ojs_ynh · GitHub

May be adding the domain and path to the command helps : https://$domain/$path/register

I remember I had hard time to make it work. I have installed the app then tried the curl command till I got the right one

wbk · March 4, 2025, 8:23pm

The best result, giving “page expired”, is attained with

ynh_local_curl "/index.php/register" "name=$user" "email=$email" "password=$password" "password_confirmation=$password"

The install log shows that it is converted to

 curl --silent --show-error --insecure --location --header 'Host: idlers.dus.osba.nl' --resolve localhost:443:127.0.0.1 --data 'name=test&email=user@testma.il&password=**********&password_confirmation=**********' https://localhost/index.php/register --cookie-jar /tmp/ynh-my_idlers-cookie.txt --cookie /tmp/ynh-my_idlers-cookie.txt

I tried adding domain and path, as well as hardcoding the URI. It fails in variations of “not found” and SSOwat.

The example in the code for ynh_curl_local makes me think I should not refer to a page, but to the ‘register’ button.

The cookie is prepared just before the command is executed; the timestamp corresponds with the last installation.

I guess for now people will have to create a user by themselves