I've got an incredibly limited calling and data plan on my cell phone, and spend most of my waking hours in front of a computer with an Internet connection. With Google Voice able to route calls through Gmail, it seems silly to pay for minutes on my phone.
I'd like to use something like Tasker on my smartphone to change my Google Voice forwarding settings automatically so that calls are only routed to my cell phone when I'm not at a computer. The trigger rules are simple enough, but Google Voice doesn't have any official API for things like this.
Has anyone had any success with changing Google Voice settings via some hacked-up API? I've seen a couple that do things like place calls and send SMS messages, but all I need is to change settings, which the ones I saw didn't support. Perhaps a little documentation on how Google Voice handles web requests currently that I could use to change things from a PHP script that I could then call from my phone?
Bonus points if I can use some sort of long-lasting login token rather than having to store my Google password in cleartext.
Related
Our water district sends out automated alarms and process statistics from a SCADA computer in our water treatment plant. The information is sent in the form of SMS messages and daily emails with csv file attachments. Because we also have an informational website on Google Sites, I would like to automatically display real-time process statistics on our website in a simple Google sheet which would be automatically updated.
I have been handling the SMS alarms through custom PHP/Twilio scripts which are separately hosted, but would like to integrate everything in the Google Cloud with Google AppEngine. I think this can be accomplished in a variety of ways, and am currently evaluating alternative automation approaches using PHP and the Gmail API. As a Google Cloud/AppEngine noob, I have a couple of architectural questions:
Can I accomplish this automation by simply enabling the Google Sheet for incoming mail and processing the data through spreadsheet scripting? If I elect this approach, can the Google Sheet receive email directly, or must I send email data to the sheet as an http request?
Alternatively, would the Google Cloud be a more reliable and robust platform for this automation? From the examples I have seen, it looks like AppEngine PHP scripts can be enabled to receive incoming email, parse required data from the email body or attachments, and form an appropriate web request directed to the Google Sheet endpoint. Under this approach, Google Sheet scripting would be minimal.
Does anybody have any constructive advice before I plunge blindly and lustfully headlong into this project? Thanks.
To answer your questions:
1/ Using Google Scripts
I think using Google Spreadsheet Scripting might be an option if your data was stored in the body text of the e-mail.
In this case you could actually write a Google Spreadsheet script which pulls the e-mails directly from your Gmail account. Instead of sending the e-mail to the spreadsheet you could access your Gmail account the GmailApp service.
However ... if you data is stored inside a CSV attachment I'm not so sure if this is feasible. I'm not sure that you can access the data inside attachments with Google Spreadsheet script.
2/ Using Google Cloud
I'm by no means an expert here. But I think you don't really need to host your code with them. Once you use PHP and leverage the Google APIs (Gmail + Google Sheets) you should be able to host your code anywhere you like.
Extra: Consider using an Email Parser Software
Developing all this yourself is feasible it will take you for sure a lot of time. E-mail is always a bit difficult to handle and you have a lot of moving parts there.
I'm the founder of mailparser.io and I believe that you would be much better of using a ready made e-mail parser software like ours for this job. We integrate natively with Google Spreadsheets and you should have something running within a couple of minutes.
My question is not deeply technical but more of a system architectural one.
I'm designing an API backend in Go Lang. I'd like to have several clients, like a web server, cell phones etc.. I imagine that all these clients should have a secret API key so to validate that they can use the API. At the same time the web frontend is going to have a lot of users with different restrictions. I'd like for these users to be able to log in with their facebook or Google account. That should require OAuth authentication as I understand. My question is now where should I add the OAuth. Only in the frontend and then save the user in session or also between the frontend and the backend. I'm highly confused about how I should set up this communication and authentication.
I'm building the web server in PHP and I'd like the web frontend to be really light weight and more or less only function as en empty shell/view for the Go API. I've build systems in plain PHP/MySQL before but I'd like to make a shift to Go based APIs.
How would a URI look like to the API from the web server frontend for let's say a show profile page? I imagine something like a GET call to "http.//backend.com:3000/[api-key]/[api-secret][oauth-token?]/profile. Then some middleware to authenticate the web client and another piece of middleware to authenticate the user. Would that be "the right" approach?
I hope you guys can point me in the right direction.
Thanks in advance.
If you look at your facebook or google developer docs, you will find examples on how to integrate with their oauth login systems.
OAuth, or at least the last step of it, really must be done on the back end as you have to assume your front end is a bad guy hitting your system.
For go oauth, take a look at: https://github.com/golang/oauth2
You will likely have a http.HandlerFunc("/oauth/google",yourGoogleFunc)
and http.HandlerFunc("/oauth/facebook",yourFBFunc)
type thing, then you register that URL on your dev account with those companies.
while testing, it's easiest to use localhost:8080 (or whatever) as the callback url so it works on any machine as long as you are using a local browser.
I would like to send notifications from my webserver to my smartphone, preferably through one of the popular mobile chat apps like WhatsApp, Viber or Kik.
Is there any known documentation or API or something, that describes how to send a message to these clients, for example using PHP?
Note that I only need to be able to send notifications to my own smartphone, so requiring specific info to identify my particular client (like cellphone number or something) is fine.
Yes there have been some, but whatsapp changed their security system and shut off the api - so there is no known way anymore.
For Example:
https://github.com/venomous0x/WhatsAPI and
http://blog.philippheckel.com/2013/07/07/send-whatsapp-messages-via-php-script-using-whatsapi/
There is a module Drupal WhatsApp
NOTICE: This module uses an unofficial API library for sending WhatsApp, which may mean that may stop working without notice.
USE THIS MODULE RESPONSIBLY AND WITHOUT USING SPAM BECAUSE THEY COULD BAN OF ITS SERVERS THE USED PHONE NUMBER.
I recently completed my first API in PHP. It is hosted at a public URL and accessed by a couple of my own mobile apps and websites. Based on a couple of parameters passed in, it pulls some data from my database and returns some JSON.
I would like to know some details about how often the API is accessed, and by what kind of clients.
Can I use google analytics for this? I have used it successfully on some websites in the same domain, but when I include the analytics php link and access the API, nothing is recorded.
Any gotchas I could be missing? Or is Google analytics only useable on web pages?
Google analytics isnt just for montiring websites, you can also use it to monitor mobile applications.
You might be able to monitor your API with the Measurement Protocol this should let you send info about the preformance of your api, and log the things you are talking about.
Note: I havent tried it but would love to hear from you if this works.
We have a website which provides time-critical updates on changes in the value of FOO, and want to deliver notifications of new data via various IM protocols.
For reasons best known to themselves (and their parents), the FOO-traders use Yahoo! Messenger, MSN, gTalk, AIM, you name it. They want to receive their updates on their desktops so they can buy and sell FOO realtime.
We want to deliver the updates to them via the various networks, without investing a huge amount of time in supporting new networks.
I'm aware of services like RPX (or whatever it's now called) and Gigya, which allow you to authenticate across multiple websites. I want something similar, but which allows us to deliver IM to the same various networks.
The service should be able to readily expose access to notifications coming from a PHP (Drupal 7) website.
The website is a paid subscription service; we are not after a cross-network spam solution. I say this (1) so you won't hate me (2) because if we wanted to send spam, that would probably preclude gateway providers.
Self-hosted solutions like PHPurple are an option also, but I haven't found much online to recommend it as an option yet.
Support for other networks will be a bonus, although I haven't seen any of the FOO-traders use Twitter yet. We will also include SMS and email notification for added old-school cred.
Through Jabber server.
Set up Jabber server
Register accounts for all the services you going to use
Register gateways, all jabber servers support them
Test through GUI jabber client
Write a daemon (or get somewhere), which logs into jabber, starts up gateways, reads messages from somewhere and sends them right away.
There are command-line utilities, but they won't work, because server won't keep gateways connected unless on it's own.
XMPP protocol is quite straightforward and has many libraries.
For reliable SMS you might need to use other, 3rd party protocols or utilities.