search

LycheeOrg / Lychee

A great looking and easy-to-use photo-management-system you can run on your server, to manage and share photos.
https://lycheeorg.github.io/
MIT License
3.42k stars 303 forks source link

/public/api/Albums::get 400 (Bad Request) #699

Closed jamesautodude closed 4 years ago

jamesautodude commented 4 years ago

Detailed description of the problem [REQUIRED]

main.js?1597871784:2 POST /public/api/Albums::get 400 (Bad Request)

I get this error and then the page reloads immediately after. I also get a glimpse of an error saying "ERROR: Session Time Out"

Also, I am using the MYSQL method to connect to database. It worked for creating all the tables just fine, so I'm not sure why it would say "username" and "password" is empty in DIAGNOSTICS since it didn't have that issue when creating the tables... I was curious though, MYSQL is actually depreciated since PHP 7.0, so does the mysql method actually use MYSQLI??

Steps to reproduce the issue

After initial setup is done, I go to the /public folder again and it'll pop up the create account dialog, but then immediately go into a reload loop with the above errors

Output of the diagnostics [REQUIRED]

Diagnostics

Error: username empty or not set in database
Error: password empty or not set in database
Warning: Dropbox import not working. dropbox_key is empty.
Warning: Pictures that are rotated lose their metadata! Please install Imagick to avoid that.

System Information
------------------
Lychee Version (release):   4.0.6
DB Version:                 4.0.6

composer install:           --no-dev
APP_ENV:                    production
APP_DEBUG:                  false

System:                     Linux
PHP Version:                7.4
MySQL Version:              5.6.49-cll-lve

Imagick:                    -
Imagick Active:             1
Imagick Version:            -
GD Version:                 2.2.5

Config Information
------------------
version:                    040006
check_for_updates:          0
sorting_Photos_col:         takestamp
sorting_Photos_order:       ASC
sorting_Albums_col:         max_takestamp
sorting_Albums_order:       ASC
imagick:                    1
skip_duplicates:            0
small_max_width:            0
small_max_height:           360
medium_max_width:           1920
medium_max_height:          1080
lang:                       en
layout:                     1
image_overlay:              1
image_overlay_type:         desc
default_license:            none
compression_quality:        90
full_photo:                 1
delete_imported:            0
Mod_Frame:                  1
Mod_Frame_refresh:          30
thumb_2x:                   1
small_2x:                   1
medium_2x:                  1
landing_page_enable:        0
landing_owner:              John Smith
landing_title:              John Smith
landing_subtitle:           Cats, Dogs & Humans Photography
landing_facebook:           https://www.facebook.com/JohnSmith
landing_flickr:             https://www.flickr.com/JohnSmith
landing_twitter:            https://www.twitter.com/JohnSmith
landing_instagram:          https://instagram.com/JohnSmith
landing_youtube:            https://www.youtube.com/JohnSmith
landing_background:         dist/cat.jpg
site_title:                 Lychee v4
site_copyright_enable:      1
site_copyright_begin:       2019
site_copyright_end:         2019
additional_footer_text:     
display_social_in_gallery:  0
public_search:              0
SL_enable:                  0
SL_for_admin:               0
public_recent:              0
recent_age:                 1
public_starred:             0
downloadable:               0
photos_wraparound:          1
map_display:                0
zip64:                      1
map_display_public:         0
map_provider:               Wikimedia
force_32bit_ids:            0
map_include_subalbums:      0
update_check_every_days:    3
has_exiftool:               0
share_button_visible:       0
import_via_symlink:         0
has_ffmpeg:                 0
location_decoding:          0
location_decoding_timeout:  30
location_show:              1
location_show_public:       0
rss_enable:                 0
rss_recent_days:            7
rss_max_items:              100
prefer_available_xmp_metadata: 0
kamil4 commented 4 years ago

Could you post your .env file? (feel free to skip the DB_USERNAME and DB_PASSWORD, of course)

You are not blocking any of the cookies in your web browser that Lychee sets, do you?

As to the errors in Diagnostics about empty username/password, it's referring to the Lychee admin account (that you normally set up when you first bring Lychee up in the web browser), not to the database user/password. Given the problems you have, it's normal that those are not set.

And yes, I seem to remember that we use mysqli.

jamesautodude commented 4 years ago

Could you post your .env file? (feel free to skip the DB_USERNAME and DB_PASSWORD, of course)

You are not blocking any of the cookies in your web browser that Lychee sets, do you?

As to the errors in Diagnostics about empty username/password, it's referring to the Lychee admin account (that you normally set up when you first bring Lychee up in the web browser), not to the database user/password. Given the problems you have, it's normal that those are not set.

And yes, I seem to remember that we use mysqli.

Okay just checking. I do not have any blocked but watching in Developer Tools (Chrome), Application -> Storage, under COOKIES, I do see a XRSF-TOKEN and LYCHEE_SESSION being set. Every refresh the value changes for both of them though.

Here is the .env file:

APP_NAME=Lychee APP_ENV=production APP_KEY=base64:FM824rm6ld9ZGf3oEvRvj38/BtUmhw5cl6kmyFq2aEo= APP_DEBUG=false APP_URL=https://*myURL*.com/galleries/

application is within /galleries folder. Public folder is within /galleries folder

enable or disable debug bar. By default it is disabled.

DEBUGBAR_ENABLED=false

LOG_CHANNEL=stack

Table prefix (e.g. lychee_) of a Lychee v3 instance for migration

DB_OLD_LYCHEE_PREFIX=

DB_CONNECTION = mysql DB_HOST = localhost DB_PORT = 3306 DB_DATABASE = CORRECT DATABASE WAS HERE DB_USERNAME = CORRECT USERNAME WAS HERE DB_PASSWORD = CORRECT PASSWORD WAS HERE DB_LOG_SQL = false

TIMEZONE=UTC

folders in which the files will be stored

LYCHEE_DIST="/var/www/html/Lychee-Laravel/public/dist/"

LYCHEE_UPLOADS="/var/www/html/Lychee-Laravel/public/uploads/"

url to access those files

LYCHEE_DIST_URL="dist/"

LYCHEE_UPLOADS_URL="uploads/"

BROADCAST_DRIVER=log CACHE_DRIVER=file SESSION_DRIVER=file SESSION_LIFETIME=120 QUEUE_DRIVER=sync

SECURITY_HEADER_HSTS_ENABLE=false

REDIS_HOST=127.0.0.1 REDIS_PASSWORD=null REDIS_PORT=6379

MAIL_DRIVER=smtp MAIL_HOST= MAIL_PORT= MAIL_USERNAME= MAIL_PASSWORD= MAIL_ENCRYPTION=

PUSHER_APP_ID= PUSHER_APP_KEY= PUSHER_APP_SECRET= PUSHER_APP_CLUSTER=mt1

MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}" MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"

jamesautodude commented 4 years ago

I found this in the logs:

file_get_contents(/home/photog11/public_html/galleries/.git/HEAD): failed to open stream: No such file or directory

d7415 commented 4 years ago

APP_URL=https://_myURL_.com/galleries/

Try setting this to APP_URL=https://_myURL_.com/galleries/public/

I found this in the logs:

file_get_contents(/home/photog11/public_html/galleries/.git/HEAD): failed to open stream: No such file or directory

https://lycheeorg.github.io/docs/faq.html#why-are-there-messages-about-git-files-in-my-logs-eg-githead-failed-to-open-stream-no-such-file-or-directory

jamesautodude commented 4 years ago

Try setting this to APP_URL=https://_myURL_.com/galleries/public/

Okay tried that, no change, still does the refreshing. I did notice it'll put "public/#" (# sign) at the end after it does the first refresh

https://lycheeorg.github.io/docs/faq.html#why-are-there-messages-about-git-files-in-my-logs-eg-githead-failed-to-open-stream-no-such-file-or-directory

So does this mean I shouldn't worry about it? It keeps adding that log every time it refreshes too. I installed Lychee by uploading the ZIP files to my cloud server.

d7415 commented 4 years ago

Okay tried that, no change, still does the refreshing. I did notice it'll put "public/#" (# sign) at the end after it does the first refresh

Ok. Worth a try as your setup is nonstandard.

So does this mean I shouldn't worry about it? It keeps adding that log every time it refreshes too. I installed Lychee by uploading the ZIP files to my cloud server.

It's not causing your issues - just a side effect of how we work. We should probably try to hide it, but that's a low priority.

jamesautodude commented 4 years ago

Okay tried that, no change, still does the refreshing. I did notice it'll put "public/#" (# sign) at the end after it does the first refresh

Ok. Worth a try as your setup is nonstandard.

So does this mean I shouldn't worry about it? It keeps adding that log every time it refreshes too. I installed Lychee by uploading the ZIP files to my cloud server.

It's not causing your issues - just a side effect of how we work. We should probably try to hide it, but that's a low priority.

So should I just move on from trying to use this? maybe it's best to put some kind of warning that it's only for composer users or something then.... The 3.0 versions worked fine

d7415 commented 4 years ago

People have managed to get v4 working without command line access, but it does complicate things. The less access you have to configure your webserver, PHP, etc, the harder it is to debug things or to fix strange behaviour.

Someone might come up with another idea - remember this is taking time for us to think about too, and you seem to be the first to have this specific error.

kamil4 commented 4 years ago

Well, I can tell you that the message you are seeing looks familiar to me since I'm the one who implemented it :smiley: (see #279 and https://github.com/LycheeOrg/Lychee-front/pull/114).

You normally get that message after a period of inactivity exceeding the SESSION_LIFETIME value from .env (expressed in minutes). So I was hoping that you accidentally had it said to 0 or something. But your .env looks fine so I don't know what to think of it...

You also see the same cookies that I do so that can't be the issue either...

Yeah, we don't know what to tell you...

Yavieh commented 4 years ago

I have the same problem. I also tried to change settings in the .env but no success. The Database connection seems fine, all tables are created and the logs are written. I get this in the chrome console: main.js?1590493985:2 POST /api/Albums::get 400 (Bad Request) And this in the logs: file_get_contents(/share/CACHEDEV1_DATA/Web/Lychee/.git/HEAD): failed to open stream: No such file or directory

jamesautodude commented 4 years ago

I have the same problem. I also tried to change settings in the .env but no success. The Database connection seems fine, all tables are created and the logs are written. I get this in the chrome console: main.js?1590493985:2 POST /api/Albums::get 400 (Bad Request) And this in the logs: file_get_contents(/share/CACHEDEV1_DATA/Web/Lychee/.git/HEAD): failed to open stream: No such file or directory

Glad I'm finally not the only one... I use iFastNet as my host and I noticed that there's a Mod Security that would cause a bunch of issues, so I disabled it but haven't had a chance to test it with installing this gallery manager yet. Maybe that's what's going on? Tech support on ifastnet said that it blocks a lot of stuff from being created and whatnot so worth looking into... I plan to try it again soon and see if it fixed the issues

jamesautodude commented 4 years ago

I have the same problem. I also tried to change settings in the .env but no success. The Database connection seems fine, all tables are created and the logs are written. I get this in the chrome console: main.js?1590493985:2 POST /api/Albums::get 400 (Bad Request) And this in the logs: file_get_contents(/share/CACHEDEV1_DATA/Web/Lychee/.git/HEAD): failed to open stream: No such file or directory

Also from what I've read online, the .git library has something to do with installing this gallery using a different method other then just putting the files in. I think the creators mainly focused on having this installed using a different method and didn't focus on just putting the files on a server... Which might be why we get that error because the .git files don't get installed if you put the files on the server manually. If that makes sense...

Yavieh commented 4 years ago

I treid to host it myself on a Qnap Nas. All PHP requirements are good, but maybe its some permission control issue? The webserver has all rights to read and write.

jamesautodude commented 4 years ago

I have the same problem. I also tried to change settings in the .env but no success. The Database connection seems fine, all tables are created and the logs are written. I get this in the chrome console: main.js?1590493985:2 POST /api/Albums::get 400 (Bad Request) And this in the logs: file_get_contents(/share/CACHEDEV1_DATA/Web/Lychee/.git/HEAD): failed to open stream: No such file or directory

It says on their FAQ page: Lychee checks for the presence of certain files to detect whether Lychee was installed as a git repository or from a release archive (.zip). It also uses them to determine which git commit is in use where applicable. This is included in the Diagnostics page to assist us in diagnosing issues

So I'm assuming they didn't think about the .zip method and only focused on the git repository method

jamesautodude commented 4 years ago

I treid to host it myself on a Qnap Nas. All PHP requirements are good, but maybe its some permission control issue? The webserver has all rights to read and write.

Nah I've tried every permission I could think of. I honestly think it's because they didn't code the .zip method of installing

Yavieh commented 4 years ago

Okay thats a problem. I think i dont have access to composer on my Nas. So i need to host it somewhere else maybe?

jamesautodude commented 4 years ago

Okay thats a problem. I think i dont have access to composer on my Nas. So i need to host it somewhere else maybe?

Yeah from what everyone was telling me, the .zip method is a non-standard way of installing it and my guess is that the creator didn't bother 100% verifying that it'd work that way... So if you have a way to use the git repository method, you'd be good to go

jamesautodude commented 4 years ago

Okay thats a problem. I think i dont have access to composer on my Nas. So i need to host it somewhere else maybe?

It sucks too because this is really the only decent album/photo manager I could find out on the internet but installing it is a nightmare if you can't use git repositories :(

Also all of the support you'd get is from a git repository standpoint so nobody knows how to fix any issues with the .zip method

Yavieh commented 4 years ago

Hmm okay. The v3 version was so easy to install with just the zip. So maybe i need to try the git version. It was so promissing :(

Yavieh commented 4 years ago

Did you try the docker Version?

jamesautodude commented 4 years ago

Hmm okay. The v3 version was so easy to install with just the zip. So maybe i need to try the git version. It was so promissing :(

I know right!!!! I LOVED version 3 but sadly it lacks in a lot of features/areas of this better version. But yeah, sadly the creator didn't really bother focusing on the zip method 😭 good luck on the git version. Sadly my host (iFastNet) doesn't give me that kind of access 😭

jamesautodude commented 4 years ago

Did you try the docker Version?

I haven't. Might be worth a shot. I don't have any kind of access to the server/apache/etc to be able to do those kind of module installs lol

Yavieh commented 4 years ago

Okay i have a Container Station where i can use docker. Maybe that will work :)

Yavieh commented 4 years ago

Just to let you know, i installed the git version localy with composer and its working. Seems to be as you mentioned that the zip version has problems.

ildyria commented 4 years ago

FYI, we do test the zip file created. So stop spouting non-sense. https://github.com/LycheeOrg/Lychee/blob/55d9dacc96215b00b92facd52efa0b7ff37b6eab/.travis.yml#L76

https://github.com/LycheeOrg/Lychee/blob/master/test_dist.sh

d7415 commented 4 years ago

To clarify, we test the zip version and have many users using it successfully. The issue is that hosts which require this distribution method tend to have other restrictions in place which are difficult to debug for every host, and in many cases are beyond our control (e.g. if PHP can't create files Lychee can't work).

jamesautodude commented 4 years ago

Just to let you know, i installed the git version localy with composer and its working. Seems to be as you mentioned that the zip version has problems.

Awesome! Glad to hear it!

jamesautodude commented 4 years ago

To clarify, we test the zip version and have many users using it successfully. The issue is that hosts which require this distribution method tend to have other restrictions in place which are difficult to debug for every host, and in many cases are beyond our control (e.g. if PHP can't create files Lychee can't work).

Like I said somewhere above, it could be this module called ModSecurity. I disabled it per my hosts request and I was able to do stuff like uploading without an issue. So I'm going to retry the install (as mentioned above as well) to see if that was the issue

kamil4 commented 4 years ago

Like I said somewhere above, it could be this module called ModSecurity. I disabled it per my hosts request and I was able to do stuff like uploading without an issue. So I'm going to retry the install (as mentioned above as well) to see if that was the issue

Please do!

If you still can't get it to work, please let us know. In that case, would it be possible for you to give me access to your hosting platform so that I can try to debug the issue further?

jamesautodude commented 4 years ago

Like I said somewhere above, it could be this module called ModSecurity. I disabled it per my hosts request and I was able to do stuff like uploading without an issue. So I'm going to retry the install (as mentioned above as well) to see if that was the issue

Please do!

If you still can't get it to work, please let us know. In that case, would it be possible for you to give me access to your hosting platform so that I can try to debug the issue further?

I normally would but unfortunately there's already some personal client data on there so I can't. But I'll see what happens and go from there

jamesautodude commented 4 years ago

Like I said somewhere above, it could be this module called ModSecurity. I disabled it per my hosts request and I was able to do stuff like uploading without an issue. So I'm going to retry the install (as mentioned above as well) to see if that was the issue

Please do!

If you still can't get it to work, please let us know. In that case, would it be possible for you to give me access to your hosting platform so that I can try to debug the issue further?

So the good news is that I'm not getting that error anymore now that ModSecurity was disabled and I re-installed. Now I have a new issue though, where it's just a black screen?? Nothing happens when visiting /public other then a black screen...

jamesautodude commented 4 years ago

Diagnostics only says:

Diagnostics

Error: username empty or not set in database
Error: password empty or not set in database
Warning: Dropbox import not working. dropbox_key is empty.
Warning: Pictures that are rotated lose their metadata! Please install Imagick to avoid that.

System Information
------------------
You must be logged to see this.

Config Information
------------------
You must be logged to see this.
kamil4 commented 4 years ago

Is it totally black, with literally nothing on it, or is there a header, login button, etc? Can you share the URL of your gallery?

jamesautodude commented 4 years ago

Is it totally black, with literally nothing on it, or is there a header, login button, etc? Can you share the URL of your gallery?

It's completely black, no header, nothing on the page but the black background

kamil4 commented 4 years ago

Weird... I suppose it's possible if your PHP interpreter is not working properly on some fundamental level. E.g., I just moved my bootstrap directory out of the way and that resulted in an essentially empty HTML document when I tried to open my gallery. Then again, Diagnostics works for you, so your PHP interpreter is at least somewhat operational...

Did you ever get to see the Lychee-installer (on your first access to public) or not even that? Did you start with a fresh installation after disabling that ModSecurity or are you reusing one from before? I would recommend to redo the installation from scratch...

jamesautodude commented 4 years ago

Weird... I suppose it's possible if your PHP interpreter is not working properly on some fundamental level. E.g., I just moved my bootstrap directory out of the way and that resulted in an essentially empty HTML document when I tried to open my gallery. Then again, Diagnostics works for you, so your PHP interpreter is at least somewhat operational...

Did you ever get to see the Lychee-installer (on your first access to public) or not even that? Did you start with a fresh installation after disabling that ModSecurity or are you reusing one from before? I would recommend to redo the installation from scratch...

I'll try from scratch. I mainly deleted the "installed" file and ran through the installation again after ModSecurity was disabled. but maybe other files need to be back to original for it to install correctly? I'll try that, thank you

jamesautodude commented 4 years ago

Weird... I suppose it's possible if your PHP interpreter is not working properly on some fundamental level. E.g., I just moved my bootstrap directory out of the way and that resulted in an essentially empty HTML document when I tried to open my gallery. Then again, Diagnostics works for you, so your PHP interpreter is at least somewhat operational...

Did you ever get to see the Lychee-installer (on your first access to public) or not even that? Did you start with a fresh installation after disabling that ModSecurity or are you reusing one from before? I would recommend to redo the installation from scratch...

Nah it didn't fix it. Still says Session Timeout over and over again and never lets you create an initial account. The create account will pop up but then instantly go into a reload loop saying Session Timeout... Chrome's Developer Tools says that error about the Albums::get but I did notice it says inside /public/api, and I don't see an API folder??? and it says it's inside of the main.js?1599257603:2 file

Also I noticed if I delete the lychee_session cookie/session, it'll restart to the create user account popup, but then restart the loop. So seems to me like it's something to do with the lychee_session

kamil4 commented 4 years ago

So back to square one, essentially?

Well, as I had said, without being able to poke around that host we are unlikely to be able to figure anything out. Since you are reluctant to do it due to customer data being there, how about setting up another instance for a short term, with the same config, that we could experiment with?

ildyria commented 4 years ago

No answer. This seems to be server side config related.