i've a problem with the router generator of symfony
when i'm running
dump($this->container->get('router'));exit;
on a controller my router context is like this
#context: RequestContext {#306 ▼
-baseUrl: "/my-project/web/app_dev.php"
-pathInfo: "/accueil"
-method: "GET"
-host: "localhost"
-scheme: "http"
-httpPort: 82
-httpsPort: 443
-queryString: ""
-parameters: array:1 [▶]
}
But the same code but on mailer service i get this #context: Symfony\Component\Routing\RequestContext {#312
-baseUrl: ""
-pathInfo: "/accueil"
-method: "GET"
-host: "localhost"
-scheme: "http"
-httpPort: 80
-httpsPort: 443
-queryString: ""
-parameters: []
}
i found this problem after getting urls like
"http://localhost/bundleRoute/myRoute/7" instead of
"http://localhost/my-project/web/app_dev.php/bundleRoute/myRoute/7"
THANKS.
You can configure the request context for your application when parts of it are executed from the command-line: http://symfony.com/doc/current/cookbook/console/sending_emails.html#configuring-the-request-context-globally
Related
I created a simple Vue3 app, and I'm trying to call another local API (on a different port) on my machine. To better replicate the production server environment, I'm making a call to a relative API path. That means I need to use a proxy on the vite server to forward the API request to the correct localhost port for my local development. I defined my vite proxy like this in my vite.config.ts file:
import { fileURLToPath, URL } from "node:url";
import { defineConfig } from "vite";
import vue from "#vitejs/plugin-vue";
import basicSsl from '#vitejs/plugin-basic-ssl'
// https://vitejs.dev/config/
export default defineConfig({
plugins: [
basicSsl(),
vue()
],
resolve: {
alias: {
"#": fileURLToPath(new URL("./src", import.meta.url)),
},
},
server: {
https: true,
proxy: {
'/api': {
target: 'https://localhost:44326', // The API is running locally via IIS on this port
changeOrigin: true,
rewrite: (path) => path.replace(/^\/api/, '') // The local API has a slightly different path
}
}
}
});
I'm successfully calling my API from the Vue app, but I get this error in the command line where I'm running the vite server:
5:15:14 PM [vite] http proxy error:
Error: self signed certificate
at TLSSocket.onConnectSecure (node:_tls_wrap:1530:34)
at TLSSocket.emit (node:events:526:28)
at TLSSocket._finishInit (node:_tls_wrap:944:8)
at TLSWrap.ssl.onhandshakedone (node:_tls_wrap:725:12)
I already tried to add the basic ssl package, and I don't particularly want to install the other NPM package that is in the top voted answer. Why does the vite server complain about a self signed certificate when I'm trying to call another API on my local machine? What can I do to fix this?
you could try secure: false
server: {
https: true,
proxy: {
'/api': {
target: 'https://localhost:44326', // The API is running locally via IIS on this port
changeOrigin: true,
secure: false,
rewrite: (path) => path.replace(/^\/api/, '') // The local API has a slightly different path
}
}
}
the set of full options is available at https://github.com/http-party/node-http-proxy#options
Options
httpProxy.createProxyServer supports the following options:
target: url string to be parsed with the url module
forward: url string to be parsed with the url module
agent: object to be passed to http(s).request (see Node's https agent and http agent objects)
ssl: object to be passed to https.createServer()
ws: true/false, if you want to proxy websockets
xfwd: true/false, adds x-forward headers
secure: true/false, if you want to verify the SSL Certs
toProxy: true/false, passes the absolute URL as the path (useful for proxying to proxies)
prependPath: true/false, Default: true - specify whether you want to prepend the target's path to the proxy path
ignorePath: true/false, Default: false - specify whether you want to ignore the proxy path of the incoming request (note: you will have to append / manually if required).
localAddress: Local interface string to bind for outgoing connections
changeOrigin: true/false, Default: false - changes the origin of the host header to the target URL
preserveHeaderKeyCase: true/false, Default: false - specify whether you want to keep letter case of response header key
auth: Basic authentication i.e. 'user:password' to compute an Authorization header.
hostRewrite: rewrites the location hostname on (201/301/302/307/308) redirects.
autoRewrite: rewrites the location host/port on (201/301/302/307/308) redirects based on requested host/port. Default: false.
protocolRewrite: rewrites the location protocol on (201/301/302/307/308) redirects to 'http' or 'https'. Default: null.
cookieDomainRewrite: rewrites domain of set-cookie headers. Possible values:
false (default): disable cookie rewriting
String: new domain, for example cookieDomainRewrite: "new.domain". To remove the domain, use cookieDomainRewrite: "".
Object: mapping of domains to new domains, use "*" to match all domains.
For example keep one domain unchanged, rewrite one domain and remove other domains:
cookieDomainRewrite: {
"unchanged.domain": "unchanged.domain",
"old.domain": "new.domain",
"*": ""
}
cookiePathRewrite: rewrites path of set-cookie headers. Possible values:
false (default): disable cookie rewriting
String: new path, for example cookiePathRewrite: "/newPath/". To remove the path, use cookiePathRewrite: "". To set path to root use cookiePathRewrite: "/".
Object: mapping of paths to new paths, use "*" to match all paths.
For example, to keep one path unchanged, rewrite one path and remove other paths:
cookiePathRewrite: {
"/unchanged.path/": "/unchanged.path/",
"/old.path/": "/new.path/",
"*": ""
}
headers: object with extra headers to be added to target requests.
proxyTimeout: timeout (in millis) for outgoing proxy requests
timeout: timeout (in millis) for incoming requests
followRedirects: true/false, Default: false - specify whether you want to follow redirects
selfHandleResponse true/false, if set to true, none of the webOutgoing passes are called and it's your responsibility to appropriately return the response by listening and acting on the proxyRes event
buffer: stream of data to send as the request body. Maybe you have some middleware that consumes the request stream before proxying it on e.g. If you read the body of a request into a field called 'req.rawbody' you could restream this field in the buffer option:
'use strict';
const streamify = require('stream-array');
const HttpProxy = require('http-proxy');
const proxy = new HttpProxy();
module.exports = (req, res, next) => {
proxy.web(req, res, {
target: 'http://localhost:4003/',
buffer: streamify(req.rawBody)
}, next);
};
I have Django Channels (with Redis) served by Daphne, running behind Nginx ingress controller, proxying behind a LB, all setup in Kubernetes. The Websocket is upgraded and everything runs fine... for a few minutes. After between 5-15min (varies), my daphne logs (set in -v 2 to debug) show:
WARNING dropping connection to peer tcp4:10.2.0.163:43320 with abort=True: WebSocket ping timeout (peer did not respond with pong in time)
10.2.0.163 is the cluster IP address of my Nginx pod. Immediately after, Nginx logs the following:
[error] 39#39: *18644 recv() failed (104: Connection reset by peer) while proxying upgraded connection [... + client real IP]
After this, the websocket connection is getting wierd: the client can still send messages to the backend, but the same websocket connection in Django channels does not receive group messages anymore, as if the channel had unsubscribed from the group. I know my code works since everything runs smoothly until the error gets logged but I'm guessing there is a configuration error somewhere that causes the problem. I'm sadly all out of ideas. Here is my nginx ingress:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: "nginx"
cert-manager.io/cluster-issuer: "letsencrypt-prod"
acme.cert-manager.io/http01-edit-in-place: "true"
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
nginx.org/websocket-services: "daphne-svc"
name: ingress
namespace: default
spec:
tls:
- hosts:
- mydomain
secretName: letsencrypt-secret
rules:
- host: mydomain
http:
paths:
- path: /
backend:
service:
name: uwsgi-svc
port:
number: 80
pathType: Prefix
- path: /ws
backend:
service:
name: daphne-svc
port:
number: 80
pathType: Prefix
Configured according to this and this. Installation with helm:
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install ngingress ingress-nginx/ingress-nginx
Here is my Django Channels consumer:
class ChatConsumer(AsyncWebsocketConsumer):
async def connect(self):
user = self.scope['user']
if user.is_authenticated:
self.inbox_group_name = "inbox-%s" % user.id
device = self.scope.get('device', None)
added = False
if device:
added = await register_active_device(user, device)
if added:
# Join inbox group
await self.channel_layer.group_add(
self.inbox_group_name,
self.channel_name
)
await self.accept()
else:
await self.close()
else:
await self.close()
async def disconnect(self, close_code):
user = self.scope['user']
device = self.scope.get('device', None)
if device:
await unregister_active_device(user, device)
# Leave room group
if hasattr(self, 'inbox_group_name'):
await self.channel_layer.group_discard(
self.inbox_group_name,
self.channel_name
)
"""
Receive message from room group; forward it to client
"""
async def group_message(self, event):
message = event['message']
# Send message to WebSocket
await self.send(text_data=json.dumps(message))
async def forward_message_to_other_members(self, chat, message, notification_fallback=False):
user = self.scope['user']
other_members = await get_other_chat_members(chat, user)
for member in other_members:
if member.active_devices_count > 0:
#this will send the message to the user inbox; each consumer will handle it with the group_message method
await self.channel_layer.group_send(
member.inbox.group_name,
{
'type': 'group_message',
'message': message
}
)
else:
#no connection for this user, send a notification instead
if notification_fallback:
await ChatNotificationHandler().send_chat_notification(chat, message, recipient=member, author=user)
I ended up adding a ping internal on the client and increasing nginx timeout to 1 day, which changed the problem but also shows it's probably not a nginx/daphne configuration problem.
gRPC services (developed in springboot) deployed as docker container on AWS linux (ec2). Started the docker image with port forwarding -p6565:6565.
Now when directly hit via BloomRPC on laptop, it worked : ec2.IP:6565 Package.Service.Method
Configured service & route in Kong:
{
"host": "ec2.IP",
"created_at": 1588403433,
"connect_timeout": 60000,
"id": "e657d8df-6247-458a-a8e8-bec00c41e03c",
"protocol": "grpc",
"name": "aws-grpc1",
"read_timeout": 60000,
"port": 6565,
"path": null,
"updated_at": 1588403433,
"retries": 5,
"write_timeout": 60000,
"tags": null,
"client_certificate": null
}
Route:
{
"strip_path": false,
"path_handling": "v0",
"updated_at": 1588403452,
"destinations": null,
"headers": null,
"protocols": [
"grpc",
"grpcs"
],
"created_at": 1588403452,
"snis": null,
"service": {
"id": "e657d8df-6247-458a-a8e8-bec00c41e03c"
},
"name": "aws-grpc1-route1",
"methods": null,
"preserve_host": false,
"regex_priority": 0,
"paths": [
"/grpc2"
],
"sources": null,
"id": "5739297e-3be7-4a0d-8afb-cfa8ed01cec2",
"https_redirect_status_code": 426,
"hosts": null,
"tags": null
}
Now hitting it via grpcurl -> its not working:
grpcurl -v -d "{}" -insecure ec2.ip:8443 package.service.pingMethod
Error invoking method "package.service.ping": target server does not expose service "package.service"
Here is kong config which looks related:
"proxy_listen": [
"0.0.0.0:8000 reuseport backlog=16384",
"0.0.0.0:8443 **http2** ssl reuseport backlog=16384"
],
So here are queries:
(1) can 8000 also be configured for https as insecure -> via passing a env KONG_PROXY_LISTEN variable at time of kong-container start by
-e "KONG_PROXY_LISTEN=0.0.0.0:8000 http2, 0.0.0.0:8443 http2 ssl"
Is this good to do?
(2) How to enable server side reflection? OR what is use of /grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo ?
You need to expose HTTP2 Proxy Listener for Kong.
You can refer to this one: https://konghq.com/blog/manage-grpc-services-kong/
In short, you need to add env variable details for KONG_PROXY_LISTEN like so:
-e "KONG_PROXY_LISTEN=0.0.0.0:8000 http2, 0.0.0.0:8443 http2 ssl, 0.0.0.0:9080 http2, 0.0.0.0:9081 http2 ssl"
Note: apparently Kong uses the ports 9080 for HTTP2 and 9081 for HTTP2 SSL. But I think this can be changed.
And also expose those 9080 and 9081 ports like so, this is example for docker run command:
-p 127.0.0.1:9080:9080 \
-p 127.0.0.1:9081:9081
And use the 9080 port in grpcurl when you try to request, like so:
grpcurl -v -d '{"name": "Ken"}' -plaintext localhost:9080 facade.GreetingService/SayHello
More updates:
gRPC deployed behind kong.ingress is working fine:
grpcurl -v -d "{\"greeting\":\"111\"}" -insecure acfb0xxxxx.elb.us-east-2.amazonaws.com:443 hello.HelloService.SayHello
Response:
Resolved method descriptor:
rpc SayHello ( .hello.HelloRequest ) returns ( .hello.HelloResponse );
Request metadata to send:
(empty)
Response headers received:
content-type: application/grpc
date: Sat, 02 May 2020 07:00:17 GMT
server: openresty
trailer: Grpc-Status
trailer: Grpc-Message
trailer: Grpc-Status-Details-Bin
via: kong/2.0.3
x-kong-proxy-latency: 1
x-kong-upstream-latency: 9
Response contents:
{
"reply": "hello 111"
}
Response trailers received:
(empty)
Sent 1 request and received 1 response
when configured on kong-API-gateway, it is not working:
grpcurl -v -d "{\"greeting\":\"111\"}" -insecure kong.ce-gateway.ip:8443 hello.HelloService.SayHello
Error invoking method "hello.HelloService.SayHello": failed to query for service descriptor "hello.HelloService": rpc error: code = Internal desc = An invalid response was received from the upstream server
Http2 is now enabled by default for Kong, but if you are having issues, a good place to start is to inspect the proxy_listeners section of the global config. In my case, I found that http2 was only enabled for the SSL port, and not for the non SSL. A good way to see the global config is to send a GET request to the root url of the admin api, for example GET http://localhost:8001/.
I've been trying to figure out why I'm getting CORS issues with my Symfony 4 API application I've just deployed to my Apache server and can't make any sense of the issue.
config/packages/nelmio_cors.yaml
nelmio_cors:
defaults:
origin_regex: true
allow_origin: ['%env(CORS_ALLOW_ORIGIN)%']
allow_methods: ['GET', 'OPTIONS', 'POST', 'PUT', 'PATCH', 'DELETE']
allow_headers: ['Content-Type', 'Authorization']
max_age: 3600
paths:
'^/': ~
.env
...
CORS_ALLOW_ORIGIN=/*/
...
All responses from requests I make from my localhost front-end application to that API contain no Access-Control-Allow-Origin header, and I get the standard error;
Access to XMLHttpRequest at 'http://my-api.com/foo' from origin
'http://localhost:4200' has been blocked by CORS policy: Response to
preflight request doesn't pass access control check: No
'Access-Control-Allow-Origin' header is present on the requested
resource.
No special headers are being sent and for now I've set the allowed origin regex to "all" so I can't work out what is causing issue here. I've even checked within the cache to ensure the origin is being correctly pulled from the env variables, which it is. If other context/file content is required to assist please let me know!
I always try to be a bit more specific for allowing CORS like:
CORS_ALLOW_ORIGIN=^http://(.*:8080|localhost:4200)$
what you could try if you really want to enable all origins would be something like:
CORS_ALLOW_ORIGIN=^.*$
Your problem is that you've opted to use a regular expression (origin_regex: true) but not provided valid pattern.
If you want to use origin_regex: true then you should specify a valid pattern such as .* or ^.*$.
If you don't want to use a regular expression then omit the origin_regex setting (or set it to false) and just use * as your CORS_ALLOW_ORIGIN value.
I've resolved the issue, and although on the surface it appeared to be related to the CORS configuration, it was actually misconfiguration of the project on the server.
TL;DR is that the project was missing a .htaccess file which I didn't require in development due to using Valet - following the instructions here resolved the issue.
Why do you need nelmio?
You can have simple event listener(on kernel.event_subscriber) adding these headers.
namespace App\EventListener\HttpKernel;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;
use Symfony\Component\HttpKernel\KernelEvents;
use Symfony\Component\HttpKernel\Event\FilterResponseEvent;
class CorsSubscriber implements EventSubscriberInterface
{
public static function getSubscribedEvents(): array
{
return [
KernelEvents::RESPONSE => 'onResponse'
];
}
public function onResponse(FilterResponseEvent $filterResponseEvent)
{
$response = $filterResponseEvent->getResponse();
$response->headers->set('Access-Control-Allow-Origin', '*');
}
}
Register it as kernel.event_subscriber
app.http_kernel.cors_subscriber:
class: App\EventListener\HttpKernel\CorsSubscriber
tags:
- { name: kernel.event_subscriber }
I'm using RabbitMQ Bundle for the Symfony2 web framework. My question is, how can I avoid creating multiple connections (to prevent overloading the broker) after running many workers in terminal? In example below, I've run two workers and ended up having two connections/channel.
config.yml
old_sound_rabbit_mq:
connections:
default:
host: 127.0.0.1
port: 5672
user: guest
password: guest
vhost: /
lazy: true
producers:
order_create_bmw:
connection: default
exchange_options: { name: order_create_ex, type: direct }
queue_options:
name: order_create_bmw_qu
routing_keys:
- bmw
consumers:
order_create_bmw:
connection: default
exchange_options: { name: order_create_ex, type: direct }
queue_options:
name: order_create_bmw_qu
routing_keys:
- bmw
callback: application_frontend.consumer.order_create_bmw
services.yml
services:
application_frontend.producer.order_create_bmw:
class: Application\FrontendBundle\Producer\OrderCreateBmwProducer
arguments:
- #old_sound_rabbit_mq.order_create_bmw_producer
Producer
namespace Application\FrontendBundle\Producer;
use Application\FrontendBundle\Entity\Order;
use OldSound\RabbitMqBundle\RabbitMq\ProducerInterface;
class OrderCreateBmwProducer
{
private $producer;
public function __construct(ProducerInterface $producer)
{
$this->producer = $producer;
}
public function add(Order $order)
{
$message = [
'order_id' => $order->getId(),
'car_model' => $order->getCarModel(),
'timestamp' => date('Y-m-d H:i:s')
];
$this->producer->publish(json_encode($message), 'bmw');
}
}
Running workers
$ app/console rabbitmq:consumer order_create_bmw
$ app/console rabbitmq:consumer order_create_bmw
RabbitMQ Management
Every client (regardless if publisher or subscriber) that connects to rabbitmq will create a connection. Aside from using less clients, I can't think of any other way to achive this. I also can't think of a reason to do so :) If it's performance, than actually having more subscribers will help to "empty" the exchanges (and queues).