Issue in setting up inbound calling with FreePBX in docker with a DID number? - mobile

I have a DDI number +8XXXXXXXXXXXXXX from sip.ippi.fr and I tried setting it directly on zoiper phone and when I made a call from my mobile number it worked. I want to set this inside freePBX.
So, I set up a trunk with all the sip.ippi.fr details and I created a inbound route with "+8XXXXXXXXXXXXXX" (and once with the +) "8XXXXXXXXXXXXXX" as my DID number and set the destination as an extension. I have given the context as "from-trunk" in the trunk.
Now, when I try to call this DID number over the phone, I just get an reply that the number is not available. I checked the CDR reports, there is nothing updated there. So the call does not reach the server at all.
I am using asterisk 13 with freepbx setup on docker. Is there any configuration that I am missing ?

You need to register to your provider directly as you did with zoiper. Try to register your asterisk to the sip.ippi.fr so that provider can route the calls to your freepbx, then you can distribute the call whatever you like.

Related

Identity Server 4 AuthorizationContext.PromptModes empty

I am using the oidc-client library to authorize with our own Identity Server 4. It is working fine and I need to extend the login functionality. I'd like to use the OIDC-Parameter "prompt". The parameter is sent correctly to the connect/authorize endpoint. When the Login-Method is called, I am trying to get the AuthorizationContext by calling
var context = await _interaction.GetAuthorizationContextAsync(vm.ReturnUrl);
var prompt = context.PromptModes;
_interaction is an instance of IIdentityServerInteractionService. The PromptModes are always empty. Is this the right way I am trying to access them?
Thank you
It looks like you check the value in an inappropriate place.
The answer for a similar question on Github was:
we have to remove the prompt parameter because we would otherwise run into an endless loop. You could save the parameter in a separate parameter I guess.

Retrieving the route parameter in Next 9 when loading a page directly?

I'm trying the get the route parameter in Next 9 and all the examples in the docs make sense and work. Here https://nextjs.org/learn/basics/clean-urls-with-dynamic-routing/dynamic-routing and here https://nextjs.org/docs#imperatively
My problem is that these examples are all in the context of navigating to a page from a link, I would like to load the page directly from the url.
If I go to localhost:3000/meeting/123 it loads the index page, not teh page nested in the meetings folder.
The query parameter shows the 'asPath' key with eth value 'meeting/123' so its all working but it doesn't actually use the code at pages/meeting/[meetingId].js
How do I load a dynamic route directly from the url?
For anyone else reading this, this works absolutely fine, false alarm, I just forgot to remove my customer server setup that I had for this previously. To do this prior to next 9 you had to set up a custom server and startup using the server. I set everything up for version 9 but was still starting up in teh custom server. Leaving this up here in case anyone else makes teh same mistake.

AssertionConsumerServiceURL from AuthnRequest not from Config

Noticed that the Saml2AuthnResponse Destionation is set based on the relyingParty.SingleSignOnDestination which is retrieved from a "configuration" (harcoded relyingParties array).
I think the Destination should be based on what is set in the AuthnRequest samlp:AuthnRequest -> AssertionConsumerServiceURL and use the relyingParty Destination maybe as a fallback if its missing from the AuthnRequest, but from what I see every AuthnRequest contains the ACS URL.
Or is there a reason why it is implemented this way ?
Thanks
It is part of the security only to replay known URLs/domains. Therefore it is important to configure the relyingParty.SingleSignOnDestination for each relying party.
To have a dynamic response URL you can extend the code to verify that the authnRequest.AssertionConsumerServiceUrl starts with the value in relyingParty.SingleSignOnDestination.
E.g. the value in relyingParty.SingleSignOnDestination could be "https://somedomain.com"
and thereby accept different authnRequest.AssertionConsumerServiceUrl like "https://somedomain.com/auth/AssertionConsumerService" or "https://somedomain.com/acs"

Is this a Bot modifying my URLs for some tracking purpose?

I don't know if this is bad code on our part, or a bot/spider doing something for tracking purposes. What I'm seeing is our URLs are getting modified, and it's generating site errors and error emails that I'm set up to get when it seems like my site is being hacked.
For example, a URL that should read/load like this
http://site.com/page.asp?pid=915411&order=Date
gets loaded like this
http://site.com/page.asp?pid=-1'&order=Date
the email I get shows
query string = pid=-1%27&order=Date
The IP address that comes up in the error emails always change, but many point to Kiev or Minsk, but are so varied I don't see how I can stop this from happening easily. My site is on an IIS 7.5 server, win2008.
Someone is trying to hack your application. They are testing if your application uses values from the forms or URL directly into SQL statements.
This hacking attempt is easy and called "SQL injection". Check your application if it is vulnerable, fix it immediately if required.
Additionally, try to track the attackers and if you see them coming from a set of IP addresses, block them.
Using HTTP_REEFER we are able to control the URL Modifying on directly.
Try the below code
if Request.ServerVariables("HTTP_REFERER") = "" Then
RESPONSE.WRITE " <b><h1><font color=blue></font><font color=red>UNSECURED MENU ACCESS</font><font color=blue></font><h1></b> "
response.end
End if

Icinga - How can I set custom contacts for services per hosts

I would like to set different contacts for same service based on from which host the service is called.
I've tried to use macro, but it gets translated only when command is called.
Then I've tried to edit command itself, but I think that variable CONTACTEMAIL is managed internally by icinga. I don't feel comfortable with adding only pure emails to some custom macro defined in HOST.
define command{
command_name notify-service-by-email
command_line /usr/bin/printf "%b" "***** Icinga *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$\n" | /bin/mail -s "** $NOTIFICATIONTYPE$ Service Alert: $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
}
Did anyone try/solve this?
You can define your contact on the host and delete it from services. This way every service in that host will inherit its contacts, if you define a contact again in the service it will ignore the previous one.
If the contacts depends on each service and not host, you will have to define same service for each host/contact.
$CONTACTEMAIL$ is a macro for the contact object, referencing to the attribute "email". Your command "notify-service-by-mail" will be assigned to such a contact as "service_notification_command" and that contact assigned to a service then (or via contactgroup). So once a notification happens, all required information is available and the core will translate the macro $CONTACTEMAIL$ to the real value and pass the converted string to the shell for execution then.
I would go for 2 options
use implied inheritance (http://docs.icinga.org/latest/en/objectinheritance.html), and only define contacts for the host, and not the service below. the configuration parser will recognise that contacts should be inherited and your services will get only the related host's assigned contacts then. Though, this may get ugly in terms of not wanting to notify the host alerts to the same contacts as for the service themselves.
making this more dynamic, i.e. setting service contacts based on their hostname, i would suggest using a config (generation) tool, allowing you e.g. manipulate the service->host relation with the defined contacts then. Though, there seems not really a generic solution out there... I would give LConf a try with the ldap tree itsself, but not sure if this would work out here, rather than writing a custom script, or use some puppet magic.

Resources