I'm having troubles setting up the API username/password from VoIP Innovations in my RestComm AMI.
I've followed the steps described here but the AvailablePhoneNumbers api call returns an empty list.
Then I accessed the instance via ssh and checked for the restcomm.conf file in the standalone folder. My VoiceRSS key was there but the not the VI credentials. I spent some time looking at the other files in $RESTCOMM_HOME and I found one of particular interest: $RESTCOMM_HOME/bin/restcomm/autoconfig.d/config-restcomm.sh
In that file the configVoipInnovations method call was commented and even if it wasn't commented it requires a third argument (the VI endpoint ID, which I'm not sure if it refers to the VI Endpoint Group ID or something else) that wasn't mentioned in the link above.
I also tried editing $RESTCOMM_HOME/standalone/deployments/restcomm.war/WEB-INF/conf/restcomm.conf directly with
<voip-innovations>
<login>my VI Api username</login>
<password>my VI Api password</password>
<endpoint>my VI endpoint group id</endpoint>
<uri>https://backoffice.voipinnovations.com/api2.pl</uri>
</voip-innovations>
But it didn't seem to work. The AvailablePhoneNumbers still returned an empty list.
What am I missing?
#nbermudezs,
In order to send/received SMS you should register an SMS enabled DID. Unfortunately you cannot register such DID via the Admin UI (in contrast with voice DIDs). You should go to your VoipInnovations account dashboard and search for SMS enabled DIDs there. Register the SMS enabled DID of your choice first in VoipInnovations back office and then simply go to Restcomm Admin UI -> Numbers -> +Register Number. From the drop down menu choose US as Country, select the area code for the DID of your choice and in the Number field enter the actual number (without the area code in front of it) then click register. After that you should be able to send/receive SMS from/to your newly registered DID.
#nbermudezs,
Sorry that you are having problems configuring Restcomm for Voip Innovations. When you are using Restcomm AMI, it already comes pre-configured with a default (Demo) Voip Innovation account that will automatically provision DIDs and allow you to choose an Area Code in the United States. Because the configuration script will automatically default to the pre-configured Voip Innovations account, modifying the restcomm.xml file will not work work as expected. Did you try to provision DID using the Admin UI?
On the AMI, this is how to set your VI information
Go to the directory /opt/telestax/restcomm/current/bin/restcomm
edit the file restcomm.conf
Go to the section below and fill out your VI account details. The must be set to PROVISION_PROVIDER='VI'
# DID Provision provider variable declarations
PROVISION_PROVIDER='' # values: VI (VoipInnovation), BW (Bandwidth), NX (Nexmo), VB (Voxbone)
#Username and password for all supported DID provision providers
DID_LOGIN=''
DID_PASSWORD=''
# VoipInnovation Endpoint ID
DID_ENDPOINT=''
Save your changes
You must restart Restcomm as follows
restcomm_stop
restcomm_start
Related
I am pretty sure my understanding is correct but since I cannot find any Google documentation that explicitly highlights this I wanted to ask here.
Per https://developers.google.com/apps-script/guides/triggers/installable:
Installable triggers always run under the account of the person who created them.
And we know that when you create a trigger it will ask to authorize for all the scopes the script uses.
Then, that means that anyone with edit access to the script could leverage the Google identity of the user used to create the trigger to access the scopes the trigger is authorized for.
For example:
User 1 creates a Google Apps Script that uses GmailApp to send an e-mail
(i.e. GmailApp.sendEmail("one#example.com", "test subject", "email body");)
User 1 creates a trigger to run said script every hour and authorizes it with the appropriate GmailApp scopes
User 1 gives User 2 edit access to said script
Now, User 2 can go into said script and make changes to the code and access User 1's Gmail account. For example, user 2 could change the code to:
var emails = GmailApp.search("search string to find sensitive emails")
// use GmailApp.sendEmail to forward those details to someone else like User 2
All they would have to do is make changes to the code and save; they wouldn't need to re-create the trigger since it already exists. And the next time the trigger runs it would run the newer/updated code.
I was able to confirm this behavior by creating a test script on one of my accounts and giving another account edit access.
So my question is, what is the official/recommended way to mitigate this risk? The obvious answer is to not give anyone else edit access but what if that is not an option -- what if for support purposes multiple people need to be able to access the script, then what?
As you say, the only official/recommend way is to limit editing access to trusted persons.
In your particular example, User 1 could have chosen MailApp instead of GmailApp. The two seemingly redundant services are available separately because MailApp has very limited privledges exposed compared to GmailApp. (For instance, User 2 cannot search the victims Gmail with the MailApp service.)
You can collaborate while avoiding giving direct access to your script file using clasp and git. Only you push with clasp to the script. Everyone else submits changes through git. You can setup the system to be fully automatic (i.e. a git push triggers a clasp push) or manual (i.e. you review all changes first), bit either way you have good records of who did what, when with git.
There's inherent trust when you provide edit access to the script project. You either trust the person or don't trust them. There's no inbetween.
Some "theoretical" ways you may still protect the data:
Create and use different Google accounts.
Install Triggers at the specific deployment/not at Head:
Possible only if done manually. Installable triggers created programmatically can only be used at Head
When you deploy a web-app/api, You can deploy it a specific version.
This deployment version can then be provided, When you create a new trigger for a project here.
There is no need for a working web-app/api. We're only looking to get a deployment id.
In this way, even if user changes the script, your trigger will only run at the old version deployed.
Deployed versions can be seen at Publish> Deploy from manifest.
As the previous answer states, git would be a better call.
For all practical purposes, any data you share with a malicious entity should be considered compromised.
We're developing a Gmail Addon to help internal staff to handle customers' email.
Our card widget will have a table with 2 column; first cell of every row will host, one or more domains, and the 2nd one will contains an editable text box with the default label that the addon will add to this user.
I'd like to allow user to change the default label, to adapt to his/her preferences and actual labelling method, adopted in some cases since years.
So the problem: how to save the user preferences, the user settings, of our addon only of course, but keeping related to user account? The goal is allow user to login with different devices and find the same settings
The sample Gmail add-ons projects that Google have published on Github should help you. In particular I've just found this Settings.js source file.
The core seems to be
var savedSettings = cachedPropertiesForUser_().get("settings", {});
But I've not used this in anger.
Some background and my challenge:
Background
I am using Magento 2.x using a virtual machine set-up which runs on Ubuntu 16.04
Challenge
My goal is to be able to test emails sent to me from the Magento application. In an ideal situation, I would not use an extension or third-party service (although a third-party SMTP server on the linux box could work).
To achieve my goal, I need to be able to register as a customer in the Magento application with any email address (fake or real) and have the email sent to the same external email address, no matter what.
What I've done so far
I've installed postfix
I've installed Magento using luma.com as the domain (and set up my hosts file accordingly on my host machine, etc.)
I've created a linux user account called "contact"
I've configured inet_interfaces in /etc/postfix/main.cf as loopback-only
I've set mydestination to $myhostname, localhost.$mydomain, $mydomain
I've configured Magento to send its store emails from contact#luma.com
I've set up an aliases file as the following:
postmaster: root
root: contact
contact: me#gmail.com
Then I ran newaliases As far as I recall, email sends fine with this setup. Hooray!
Next, the catch-all part. For this, I've tried loads of things, and none seem to work. From the reading I've done, I've tried the following:
In /etc/postfix/main.cf, I added the following:
virtual_alias_domains = luma.com
virtual_alias_maps = hash:/etc/postfix/virtual
Next, in /etc/postfix/virtual, I encountered my first problem. As far as I understand from the reading I've done, I'm supposed to use something like:
#example.com contact
This step apparently ensures that any email sent via postfix (e.g. from the Magento application) which uses an #example.com email address would be routed to the contact linux user I created above. Then, my thinking was that the system would use the alias I set up to ultimately send out that email from contact#luma.com (via the settings in Magento) through to the external address I set up in the aliases file. This approach would theoretically allow a user to register for an account with Magento using, say, joe#example.com, and then send the associated Welcome email to my external email address.
The issue with this is that I need the system to do this for any email, not just for emails ending in #example.com
Just for sake of completeness, I'll say that before asking this question, I was most recently researching how to achieve this part of the challenge using pcre tables. I've also tried configuring something using luser_relay, but both of these things are over my head at this point, so I'm lost.
My hope is that someone can offer some guidance as to whether I'm on the right path, where I may have missed something, and ultimately, offer some advice on whether my challenge can be solved and how I might go about solving it.
Thanks for reading.
I've install my CF on http://paas.azure4j.us
Now I want to use an eclipse plugin for CF , but when I add my CF server an error occured it said
The currently selected server type does not support remote hosts
But it works when I test it to api.vcap.me / my local CF.
Any solution ?
This looks like a similar issue addressed in a git change;
https://github.com/SpringSource/eclipse-integration-cloudfoundry/pull/2
I am not really an Eclipse user, so this is a bit of a stab in the dark!
I think Dan is correct here. At the moment you create your Cloud Foundry connection against 'localhost' (which doesn't make much sense from an Eclipse point-of-view) and in the new panel you specify your actual API target, username, password etc. Is that what you are doing?
I was able to connect to your Cloud Foundry instant without any problem using STS. First I used vmc to register for a account. Once I registered an account, I went to STS and on the server tab I right clicked, and choose Cloud Foundry from my vmware folder.
When you choose the Cloud Foundry option on the server tab, keep the Server's host name the same (which is localhost). Give a name to your Server Name and keep the Server runtime environment the same as well. Click Next to move to the next screen. On the next screen you should see Email, Password and URL. Email and password are pretty straight forward and those should be your information which you registered with your Cloud Foundry instance. For the URL section, click on the Manage Cloud... button and then the Add... button. You should get a window popup which have Name and URL. For name put whatever name you want and for URL put in "http://paas.azure4j.us", then click on Finish. Now you have your custom Cloud URL added to the list so go ahead and click on the OK button again. Now you should be on the New Server window where you have the Email, Password and URL options. For the URL option go ahead and choose the newly added url you just created and then click on "Validate Account" to see if everything is validated. You should get a "Account information is valid" message. then click on Next and continue with the wizard until you are done and you have your Cloud Foundry instance added to your servers list.
Again I have performed the same exact steps I mentioned above and I was able to have your Cloud Foundry instance added to my servers tab.
I've done this issue , so I edit my cloud_controller.yml and uaa.yml on
~/cloudfoundry/.deployment/devbox/config
Then change uaa uri at http://uaa.cloudfoundry.com to http://paas.azure4j.us:8080/ to redirect it to own uaa.
Thanks for all solutions :))
I need to create an incident (using remedy, ICM, or third party tools) automatically whenever a CRITICAL alert pops up on Nagios tool. Can anybody recommend how to do this?
In the nagios configuration where you define a contact, you have two options:
host_notification_commands
service_notification_commands
These ship with the default of host-notify-by-email and service-notify-by-email respectively, and those are defined with the command configuration option. You could define your own command, and put it next to one of the notify commands inside contacts, and It'll get run in addition to a page.
Alternatively, look for a plugin on the Nagios Exchange
An example; IRC notifications plugin:
http://exchange.nagios.org/directory/Addons/Notifications/IRC/nagircbot/details
Remedy can create incidents out of emails. Talk to your remedy admin, figure out the format the email needs to come in, and then modify the notification commands to send the email out as needed