CodeIgniter - 404 error after HTTPS configured - codeigniter

Helloooo,
I put HTTPS with letsencrypt and it works perfectly. The first page of my website is showing but after I click on a menu item, I got a 404 error.. I look into my controllers and everything is in.
Do you know any solution to this ?
Thank you :)

You need to set the AllowOverride directive in your apache configuration.
Change AllowOverride None to AllowOverride All
Set Allow Override

Related

pretty-urls not working with XAMPP and Laravel 5.8

I use Laravel v5.8 and I was happy to use it in VMware with Ubuntu. Now I needed to change to a Windows Server 2012 with xampp.
There is one thing I cannot eliminate:
I can visit my page over
https://fancysubdomain.fancydomain.de/myapplikation/public
I've created links like
<a class="title" href="/entries/create" > FOO </a>
These links go to
https://fancysubdomain.fancydomain.de/entries/create
(watch the missing "myapplication" block) and Apache tells me that the requested URL was not found.
If I type
https://fancysubdomain.fancydomain.de/myapplikation/entries/create
in the address field of the browser it also doesn't work.
In the .env file, I've set
APP_URL= https://fancysubdomain.fancydomain.de/myapplikation/
I've edited \conf\app.php to
'url' => env('APP_URL', ' https://fancysubdomain.fancydomain.de/myapplikation/'),
There are no virtual hosts set up in httpd-vhosts.conf (I am not the administrator). Do I need to set them up to get what I want? Do I need to set up something else?
You should create a Vhost which should point to the public directory of you Laravel application.
It should look like this:
<VirtualHost *:80>
DocumentRoot "path/to/laravels/public/dir"
ServerName localhost
<Directory "path/to/laravels/public/dir">
AllowOverride All
Allow from All
</Directory>
</VirtualHost>
After this is done, the default .htaccess file will work and you have pretty url's.
I’ve finally found a solution. Thanks #J. Grunder stackoverflow
After I had changed these settings, I ran into a new problem with my links.
I had created links like
<a href=”/entries/create”>Create Entry</a>
Unfortunately, now the links pointed to
https://fancysubdomain.fancydomain.de/entries/create
(watch missing myapplikation element)
Of course, I could handle that with
<a href=”/myapplikation/entries/create”>Create Entry</a>
But there could be some problems if the user is at that place.
If somebody else runs in the same problem:
Use Laravel’s URL helper:
<a href=”{{ action('EntriesController#create') }}”>Create Entry</a>

Shared Hosting proc_get_status has been disabled for security reasons

I'm trying to upload my laravel app to Cpanel. I set up everything right. It gives me the following error, though.
Please tell me how I can solve this problem?
proc_get_status() has been disabled for security reasons
Remove proc_get_status from php.ini's disabled functions in Cpanel
disable_functions = exec,execl,system,passthru,shell_exec,set_time_limit,escapeshellarg,escapeshellcmd,proc_close,ini_alter,proc_open,dl,popen,show_source,posix_getpwuid,getpwuid,posix_geteuid,posix_getegid,posix_getgrgid,open_basedir,safe_mode_include_dir,pcntl_exec,pcntl_fork,putenv,proc_get_status,proc_nice,proc_terminate,pclose,virtual,openlog,popen,pclose,virtual,openlog,escapeshellcmd,escapeshellarg,dl,show_source,symlink,eval,mail
Then override the config in Apache web server .htaccess
<IfModule mod_suphp.c>
suPHP_ConfigPath /home/path/to/public_html
</IfModule>

Magento REST API response getting 404

We configured the REST API user and permissions from magento admin side.
Then we tried the Authorization method with customer key and secret and got the access token and token secret.
Then we tried to call the API URL with OAuth version 1.0
[Magentosite]/api/rest/products
but end with a 404 error.
Also some where i found the url need to be in below format...
[Magentosite]/api.php?type=rest/products
but end with a Invalid webservice adapter specified.
Using magento version - 1.9.0.1
Can someone please suggest what is wrong in this end url calls ?
It worked and got response after we put below changes in apache file
/etc/apache2/sites-available/default
<Directory /var/www/mymagento/>
Options Indexes FollowSymLinks
AllowOverride All
</Directory>
In my case the .htaccess of the production server was missing the following line, I figured out by comparing my localhost and production server's .htacess file.
############################################
## rewrite API2 calls to api.php (by now it is REST only)
RewriteRule ^api/rest api.php?type=rest [QSA,L]
In my case, even having my localhost properly configured, I was still receiving a 404 because in my request header I wasn't sending the content type:
Content-Type:text/xml
After this first succesfull request, I was able to consume the api, and in the next requests, the content-type wasn't necesary,even if I didn't send the proper credentials, magento returns a 503, not a 404 like before.
You already answered to your problem, magento to access REST API, you got 404 url not found mostly link to missing to AllowOverride All in your apache config for the folder like as stated in https://magento.stackexchange.com/questions/29936/rest-api-returns-404
<Directory /var/www/html/magento/>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
Add your setting in /etc/apache2/apache2.conf
For anyone still getting the 404 after following all other advice, make sure that MultiViews isn't set in the Apache VirtualHost config.

ISAPI Rewrite - Helicon /user to /page.asp?username=user

Im trying to rewrite my url from this :
http://www.somedomain.com/User
to
http://www.somedomain.com/somepage.asp?Username=User
Where the =User in URL 2 is the same as the /User in URL 1. It would be great if it doesnt just redirect, but do the change in the background.
Im using Helicon ISAPI_Rewrite ver 3.
Any help would be greatly appreciated.
It seems that to do a somedomain.com/user direction is possible, BUT it will mean that all requests will be send to your redirect, as somedomain.com/user and somedomain.com/page.asp will both be redirected. For this to work you will need to handle the requests to your redirect accordingly.
What I ended up doing, as this is MUCH less work, is to just redirect somedomain.com/user/username to the page I wanted to redirect to. the rule for this, looks like follow:
RewriteEngine Off
AllowOverride none
<VirtualHost somedomain.com>
RewriteEngine on
AllowOverride all
RewriteRule ^/user/(.*) /somepage.asp?UserName=$1
</VirtualHost>
Hope this helps someone.

Tomcat application creates new session on page reload when visited through apache

We have a tomcat application which works fine in IE7/8 and Firefox. The only browser we are having issues with (that we care about at this point) is google Chrome. Users can navigate to the application fine and log in and do whatever they need to do in Firefox and IE. However, when trying to log in with Chrome, the session is apparently lost immediately after log in and when the authenticated user tries to navigate to another page they are bumped back to the log in page. This happens consistently.
I have seen other entries here and elsewhere that suggest that the context path might be to blame. I have tried setting a ProxyReverseCookiePath but that does not fix the problem.
Our virtual host configuration is as follows:
<VirtualHost xxx.xxx.xxx.xxx:80>
ServerAdmin admin#email.com
ServerName subdomain.example.com
DocumentRoot /var/www
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass /context/ ajp://127.0.0.1:8009/context/
ProxyPass / ajp://127.0.0.1:8009/context/
#ProxyPassReverse /context/ http://127.0.0.1:8009/context/
#ProxyPassReverse / http://127.0.0.1:8009/context/
#ProxyPassReverseCookiePath /context/ /
</VirtualHost>
There is another application deployed on the same instance of tomcat at the ROOT context. I have looked at the JSESSIONID that is set in the cookie, which is sent back to Chrome and it changes on every request, while it does not for IE and Firefox.
I am at a loss here. Any ideas are welcome!
We are using tomcat 6.0.23 as well as apache 2.2.14
For reference: The problem was solved by deploying the application at root context path and removing the context paths from the proxy statements.
ProxyPass /context/ ajp://127.0.0.1:8009/
ProxyPass / ajp://127.0.0.1:8009/
Nothing else was needed.

Resources