KevinTheJedi Thanks, I modified the code to reflect and its working. I'll still be bugging the hosting company about this Apache issue with another test instance.
OAuth2 "No input file specified"
Me too. I am using the default api/.htaccess
file and it's working with no mods to Apache:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} (.*/api)
RewriteRule ^(.*)$ %1/http.php/$1 [L]
</IfModule>
I did have to add the following to my main Apache config file but your host should've done this already:
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
Cheers.
KevinTheJedi I just want to give an update on this for anyone using Siteground as their hosting provider with this version (1.17) and OAuth2. I tried several different install configurations, absolutely no support from the hosting company, and a few days of frustration. Do the following before installation:
-Set SSL to your domain (obviously)
-Force HTTPS in Siteground admin panel
-Turn Caching OFF in the Speed settings menu for your site (They call it NGINX DIRECT DELIVERY)
-ONLY use PHP 8.0.24 WITH UltrafastPHP - All other 8+ versions that they offer will fail and using Standard PHP causes the "No input file specified" error
-- Then do the installation per osTicket documentation.
After those settings are changed, the OAuth2 plugin will function as designed. Big thanks to Kevin on this, he is absolutely right regarding the hosting providers and their nonsense. No need to change the URI redirect if you can get them to do their jobs or find a workable solution without changing code or api/.htaccess settings.
- Best Answerset by voidsysadmin
Absolutely wonderful and comprehensive guide. Well done my friend. It’s always a struggle with shared hosts. They always LOVE to throw the blame at the application instead of getting to the root of the issue. Kind of sad but I guess that’s how they operate these days. Always nice to hear when people work out the issue themselves and prove the hosting companies are just not helpful and downright wrong.
Cheers.
old ticket, but very impressive discussion and instructions -kudo's to KevinTheJedi, voidsysadmin & ,ntozier
-- wish i could send a 'beer' as well!
i'm having a "no input file specified" issue but am not nearly as proficient as voidsysadmin.
I'm on SiteGround, fresh install of osTicket v1.18.1, with PHP 8.2.24, and Oauth2 .6 client plugin
My question is if voidsysadmin's recommendations still hold
Or were things fixed in v.1.18 PHP 8.2.24 and/or Oauth2 .6?
-Set SSL to your domain (obviously)
-Force HTTPS in Siteground admin panel
-Turn Caching OFF in the Speed settings menu for your site (They call it NGINX DIRECT DELIVERY)
-ONLY use PHP 8.0.24 WITH UltrafastPHP - All other 8+ versions that they offer will fail and using Standard PHP causes the "No input file specified" error
-- Then do the installation per osTicket documentation.
"Full disclosure" is that this is my 1st attempt at using Oauth2, so might be something completely different.
ADVthanksANCE,
michael grimes
There is nothing for us (osTicket) to fix; so if SiteGround has not done anything to fix this then @voidsysadmin's instructions still stands.
Cheers.
Thanks for the speedy reply, K.
Sadly, there is no v8.0.24 version of PHP @Siteground -- so methinks that may have been a mistype?
8.2.24 seems more likely?
And (my problem not yours as well) using UltraFASTPHP is $13/mo more$$ -- so wanted to aske before using it.
Also wasn't sure if there were 1.18.2 changes that might have made this 'dance' unnecessary.
I'll try all these items and let this ticket know what transpires.
Again, thanks for all you do!
Best,
michael grimes
It appears they meant PHP 8.0.x specifically but that was written a while ago so at the time it was most likely a supported version.
Let me back up and explain the error so you know the root problem. The error you are getting means the server is not rewriting the URLs properly (meaning it’s not reading the api/.htaccess file as it should be) or is not directing the URLs to the correct location (ie. what the api/.htaccess file handles with its rewrite rules). With that being said let’s test something I’ve seen in other threads. Go to the api/ folder and edit the .htaccess file. All you need to do in this file is change the [L]
to [R,L]
and save it. Then restart Apache and retest.
Cheers.
KevinTheJedi...
hmm.. again, thanks for responding.
certainly changes the behavior.
now it returns a 404-Not found when looking for
but i've changed other things in the Google oAuth credentials 'state' so perhaps i should simply re-configure from the top.
And there was apparently no way to 'restart Apache' -- SiteGround 'support' (AI, not so trustworthy ;-) says simply change the .htaccess file contents.
Best regards,
miC
Try replacing the entire RewriteRule line with RewriteRule ^(.*)$ %1/http.php/$1 [R,L]
and retest.
Cheers.
Hello again KevintheJedi --
Again, so thankful for this help.
Before i read your last post, i went back to the beginning, removed any of my new osT v1181 installations and all related OAuth2 settings in GoogleCloud. i created a new 'project' and created new Oauth2 settings there. Then back to the ISP (SiteGround) and did ntozier's 'dance' for settings -- using PHP v8.2.24 was only difference from his checklist.
And now we seem to have things working for OAuth2 Google with osT v1181. So, i'm thinking this has something to do with the way i somehow badly created the OAuth2 credentials. I took more careful notes this time and maybe that helped keep me on track.
I do have a new question though,
I recall that we needed to setup a CRON job for the older v116 version of osT.
Do i need to do that as well for this v1181 version?
I'm trying to get fetching from gMail to work again on this new installation.
Or, is there perhaps a better way to collect eMail tickets using this newer version of osT.
ADVthanksANCE,
miC
Yes a cron job is needed for Linux servers (scheduled task for windows servers) to automatically poll the mailbox on a set schedule (usually every 5 minutes). Otherwise you’d have to rely on an Agent logging in and performing activity (meaning it wouldn’t fetch after hours). You can read more here:
Cheers.