I am having a problem specific to the production code. On said server, everytime I try to access specific route which is supposed to show a table of all categories I get a 502 Proxy Error:
Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request
Reason: Error reading from remote server
I have found some common problem on the internet already, however all of those were for users who use nginx. I use Laragon. Also, Laravel version is 5.5.21
As I said the problem is production code only. It is not happening when I run it locally.
I also tried to download laravel.log file from the server, but there was nothing there.
This is the function that is being called by route:
public function index(){
if(empty(request()->query()) && session()->exists('categories_filter')){
return redirect(route('categories.index').'?'.http_build_query(session()->pull('categories_filter')));
}
if(!empty(request()->query())){
$this->store_filter();
}
$categories = Category::orderBy($this->sort, $this->order);
if($name_sk = request('name_sk')){
$categories = $categories->where('name_sk', 'like', "%{$name_sk}%");
}
$categories = $categories->paginate(20);
$all_categories = Category::with('children')->get();
$sort = $this->sort;
$order = $this->order;
$new_order = $this->new_order;
return view('admin.categories.index', compact('categories', 'sort', 'order', 'new_order', 'all_categories'));
}
I honestly have no idea where the problem lies or what is its cause.
So to the people who have a similar problem, here is where my problem was:
I had a recursive blade partial component, that called itself and in every single one of those there was a sql query executed. I had to completely remake that part of my view.
So to explain it, the reason for this error is simply that I was sending too many requests to the database asking for a single row. This was a problem because once there was a moderate amount of data, it was simply taking way too long to load.
Related
I'd like to know if there's an easy fix for this error that I'm getting while trying to add support for Google sign-in to my website, since I can only reproduce it while on a Laravel-based environment. Vanilla PHP applications do run just fine.
This is my relevant code:
if ($request->has('googleToken')) {
$client = new Google_Client(['client_id' => env('GOOGLE_PLATFORM_CLIENT_ID') ]);
$payload = $client->verifyIdToken($credentials['googleToken']);
if (!$payload) {
return response([ 'error' => 'Invalid token, please try using form-based authentication.' ], Response::HTTP_FAILED_DEPENDENCY);
}
$user['googleToken'] = $credentials['googleToken'];
}
I know I'm doing too relaxed validations, but please just focus on the fact that I'm just testing and I plan to change this code in the near future.
The code above, receives its data through an Axios PUT request from the frontend with the payload looking like this:
{
googleToken: "eyJhbGciOiJSUzI1NiIsImtpZCI6IjE5ZmUyYTdiNjc5NTIzOTYwNmNhMGE3NTA3OTRhN2JkOWZkOTU5NjEiLCJ0eXAiOiJKV1QifQ.eyJpc3MiOiJhY2NvdW50cy5nb29nbGUuY29tIiwiYXpwIjoiNTkyODkzNjE3ODYzLXRscDdvaDByaTk2dTZxZGxrOXYwbHAyanQyNDlkdDNsLmFwcHMuZ29vZ2xldXNlcmNvbnRlbnQuY29tIiwiYXVkIjoiNTkyODkzNjE3ODYzLXRscDdvaDByaTk2dTZxZGxrOXYwbHAyanQyNDlkdDNsLmFwcHMuZ29vZ2xldXNlcmNvbnRlbnQuY29tIiwic3ViIjoiMTE1NTg0MDg0NTE2OTMxOTQzODU..."
mailAddress: "user#mail.com"
}
The problem is that the payload would simply return false. I decided to try to investigate the issue, so I went to the definition of verifyIdToken contained within Google_Client and, from there, jumped over to the function that finally returns to its parent, which is verifyIdToken from the class Verify.
Inside of that class, there's a pretty loose try/catch block in which I decided to try adding a generic exception case so that I could quickly print the error message for debugging. I did, and this is the output I got:
OpenSSL unable to verify data: error:0909006C:PEM routines:get_name:no start line
This is what's failing internally, and from this point on, I don't really have an idea about how to proceed since the error feels very cryptic, or at least it's not in my field of knowledge.
The OpenSSL error you quoted indicates that your client was not able to read any/further PEM-encoded data. Refer to https://www.openssl.org/docs/man1.1.1/man3/PEM_read.html.
OpenSSL unable to verify data: error:0909006C:PEM routines:get_name:no start line
Here,
'PEM routines' represents the library within OpenSSL
'get_name' is the function
'no start line' is the reason
Is you client able to access the necessary certificates/keys?
Inside ScheduleController I call ScheduleTransformer including GroupTransformer. Inside StudentController I call StudentTransformer including GroupTransformer. GroupTransformer availableInclude schedule and students
Once started the server, in postman, I execute:
1-call schedule, return OK, then call student, return error 500.
2-restart server
3-call student, return OK, then call schedule, return error 500.
4-restant server
5-...
error 500: A transformer must be a function or a class extending TransformerAbstract
removing the include in both, no error is shown
Is this error related to some sort of "cross include"?
Windows 10.
I figured out.
A problem or not, here what happens
If transformer A includes B and B includes A, whenever I call one of them, the second start bringing error 500 and the first continue working normally.
the simplest solution is put the importation inside the import, like this:
includeStudents(model) {
const StudentTransformer = use('App/Transformers/StudentTransformer')
return this.collection(model.getRelated('students'), StudentTransformer)
}
instead of up in the top of, as it is usual.
Hello I am using memcached in laravel application 5.8.
After some time the error is:
production.ERROR: Invalid argument supplied for foreach()
Code in controller is:
$page = \Request::get('page', '0');
Cache::tags('posts')->remember('page-'.$page, 15, function(){
return Post::orderBy('created_at', 'desc')
->paginate(20);
});
$posts = Cache::tags('posts')->get('page-'.$page);
The error comes, because of the #foreach loop in the view.
When I get the error, I can fix it by restarting the server, but this is not really a good solution. How can I prevent this issue and still use memcached?
I am sure that it comes from the cache, because if I change the cache driver to array than the error is gone.
Update:
So I have tried to change from remember to rememberForever in controller, but the problem remains. It errors and only solution is to turn off cache or reboot server. Otherwise it is giving me production.ERROR: Invalid argument supplied for foreach().
I'm trying to set up a prestashop webshop and I bought a theme to customize it. Instalation works great, but when reaching the live edit module of the theme I ran into a problem: after customizing the layout I tried to save my modifications, but it returns with 403 error. I've tried to debug it, I've contacted my hosting, I've contacted the developer of the theme, but noone can help me. In the error logs doesn't appear anything regarding this issue. The developer says it is tested on multiple hosts, and it works great. My host says they can't do anything if there is no error message in the logs.
I've managed to circle down the issue a little bit. There is a larger sized parameter(it contains all new configurations) which if I disable to be sent, then I get the following error: "Your hosting provider has set a non-standard or too little value of parameter LimitRequestLine in httpd.conf. Set the default setting value of parameter LimitRequestLine in httpd.conf, please." This error I receive on post and get aswell.
This parameter can be the source of my problem if the http call is through ajax post? Or there is more this issue?
I'm trying to solve this issue for 3 months now, I've spoken to the hosting firm, I've spoken to the developer of the them, I've searched a lot of forums but found no answer to this. I'm desperate to get any help on this matter.
It looks like I solved the issue with the following codes:
/public_html/modules/ixtengine/js/cpanel/cpanel.min.js
... ,$.ajax({type:"POST",url:cpfuncurl+previewfun,data:{ ...
replaced by
... ,$.ajax({type:"PUT",url:cpfuncurl+previewfun,data:{ ...
and
... ,$.ajax({type:"POST",url:cpfuncurl+savefun,data:{ ...
replaced by
... ,$.ajax({type:"PUT",url:cpfuncurl+savefun,data:{ ...
/public_html/modules/ixtengine/cpanel/functions/upload.savepf.php and /public_html/modules/ixtengine/cpanel/functions/upload.previewwid.php
...
$theme = Tools::getValue('theme');
$conf = Tools::getValue('conf');
$skin = Tools::getValue('skin');
$skinid = Tools::getValue('skinid');
$token = Tools::getValue('token');
...
replaced by
...
$put_vars=array();
if($_SERVER['REQUEST_METHOD'] == 'PUT')
{
parse_str(file_get_contents("php://input"),$put_vars);
$theme = $put_vars['theme'];
$conf = $put_vars['conf'];
$skin = $put_vars['skin'];
$skinid = $put_vars['skinid'];
$token = $put_vars['token'];
}
else
{
$theme = Tools::getValue('theme');
$conf = Tools::getValue('conf');
$skin = Tools::getValue('skin');
$skinid = Tools::getValue('skinid');
$token = Tools::getValue('token');
}
...
This solution is particulary for the ixtengine module for some hosts where POST returns 403 error so I can't be sure if this method will work for someone else running into this problem, but it works for me.
I'm using the URL::to call to embed a link in an outgoing mail message. What I get when I do this is something like: "baseroot/public/index.php/xxx/yyy".
And yet when I do the same call, for example, within a route call, I get "baseroute/xxx/yyy".
Any idea?
The source of URL::to resides at
http://laravel.com/api/source-class-Illuminate.Routing.UrlGenerator.html#76-98
(linked to from http://laravel.com/api/class-Illuminate.Routing.UrlGenerator.html).
I suggest you add debug printing to your copy and see what values $this->getScheme() and $this->getRootPath() yield. These must be the source of the discrepancy, apparently caused by different this objects.
I had a very similar problem with URL::to('user/123') returning an incorrect value when visiting the homepage vs. another page. After some investigation, in my case it was a matter of case-sensitivity (!) in the request's url. I hope it's somehow related to your mysterious case.
More about my case: URL:to('user/123') gave me different results whether I visited http://localhost/MyApp/public/someurl or http://localhost/Myapp/public/someurl. In the former it gave the correct result http://localhost/MyApp/public/user/123, while the latter gave the wrong result of http://localhost/user/123.
.
From here, less important notes from my investigation, for future Laravel archaeologists. I hope I'm not talking all nonsense. I am new to Laravel, using a local Laravel 4 installation + WAMP on a Windows machine.
UrlGenerator's to() method uses $root = $this->getRootUrl($scheme);. The latter uses $this->request->root();, where request is \Symfony\Component\HttpFoundation\Request.
Request::root() indeed defaults to a wrong value e.g. http://localhost when visiting someurl with the incorrect case.
The culprit is Symfony\Component\HttpFoundation\Request (in vendor\symfony\http-foundation\Symfony\Component\HttpFoundation\Request.php). Its getBaseUrl() calls prepareBaseUrl(), and there the actual logic of comparing the requestUri with the baseUrl is finally performed.
For the few archaeologists still following, in my case the $baseUrl was /MyApp/public/index.php while the $requestUri was /Myapp/public/someurl, which sadly led the code to not satisfy this conditional:
if ($baseUrl && false !== $prefix = $this->getUrlencodedPrefix($requestUri, dirname($baseUrl))) {
return rtrim($prefix, '/');
}