Is there AIO solution that would allow me to have:
Dashboard/backend that I can self-host (VPS)
Bot and parameters to configure booking bot and prices/availability, etc...
Simple integration with FB account to get things rolling
The idea is simple, execution probably not:
To have ready-made script/system (any language actually) which would provide me with facebook messenger bot configuration and connection to FB account.
What for and how:
Users can book an appointment via messenger, they would be presented with choices/parameters previously configured in the self-hosted backend on some domain, upon booking completion data would be stored to backend's database and available to admin for CRUD operations. Some manual and automatic notifications should be available and thats it.
Is there anything like that available?
I dont care what programming language it uses or what the requirements are, just the price.
Easyappointments would be the closest feature vise backend to what im looking for, except for the bot part...
Thanks
Related
Im reading this google doc on how to hook up app engine to a custom domain (a domain I purchased through a different registrar)
I get to a point where I have to "Supply the domain name ("example.com") and click Verify. This opens up a new tab titled Webmaster Central." and walk through some prompts to prove I own the domain.
After doing this "domain verification is automatically re-confirmed about every 30 days".
What exactly is "domain verification"? Is there like a domain verification protocol that all DNS registrars must support? What communication is happening between google and say godady or AWS (route53)? Is there a special type of DNS record specifically for verification?
I don't understand whats actually happening to prove I own the domain and if this process is standardized or each DNS provider has their own solution/quirks for doing this.
From Verify your site ownership (also accessible via the Webmaster Central help menu):
What is verification?
Verification is the process of proving that you own the site or app
that you claim to own. We need to confirm ownership because once you
are verified for a site or app you have access to its private Google
Search data, and can affect how Google Search crawls it.
No, it's not a standard. Each hosting provider asking for it had their own method/algorithm of doing it.
Google actually has several such optional methods so that you can choose one that best works for your case. They're listed in the Verification methods chapter further down in the above-mentioned doc, together with some explanation of how each of them operates. Not all of them are based on DNS registrar actions.
Also keep in mind that Webmaster Central is used for other sites as well, not only for GAE-based sites - just in case some things might not make sense in a GAE context. This includes sites not even hosted on/using Google infrastructure/services.
I need to create a (demo) application for Google Glass with a simple user interaction: insert a card on Glass and get a response back to the application.
I think this can be done by using the Mirror API.
This application is not a web application so I think I need to use a service account.
I have created an API project on the Google APIs console https://code.google.com/apis/console/ and enabled the Google Mirror API.
After that I created a new client ID with application type "service account" (calls Google APIs on behalf of your application instead of an end-user; more info at https://developers.google.com/accounts/docs/OAuth2#serviceaccount).
The result is a client id, email address and public key fingerprint and a P12 key with password.
The problem is that I cannot find an example how to do the service account authentication and for example a card insert.
Any ideas? The used programming language is less important...
See also Can I use OAUTH2 Service Accounts with Glass Mirror API? but unfortunately without an answer.
Edit:
From the answer below I understand I cannot use the service account for this.
Is it then correct that I always need a web application where Google Glass has a callback url so data can be send from Glass to the application?
We develop a Warehouse Management System where the operator in the warehouse uses a voice client (like http://www.epf-gmbh.de/bilderorg/talkman_joe.jpg) that communicates with the server. The server sends commands to the client and the operator can send voice commands back to the server.
For demo purposes I would like to replace the voice client with Google Glass.
Edit 2:
Something like this: http://youtu.be/kbcskj4yAvo
You cannot do timeline operations with a service account. Most Mirror API operations (on the Timeline, Contacts, and Subscriptions) require a user's account since these operations must be done on behalf of the user in order to correctly identify which Glass will be used.
Update:
Your followup questions don't exactly relate to the authentication question, and they may be better asked in a new question, but two quick points:
Yes, when working with the Mirror API if you want to get information from Glass into your server you'll need a webapp which can take callbacks. You'll be registering this as part of a Subscription.
The example you pointed at uses the GDK, not the Mirror API.
I'm using Google's user api on Google App Engine for authentification. As nearly everyone have a Google Account and api is easy to implement, that solution is convenient.
The problem is, though, with user who do not have a Google Account (or have no idea what a Google Account is). Where the api provides a nice interface to log in/log out and redirect immediately and easily to the app, nothing is said to developers about potential new users.
So here are a couple of things worth noticing:
Google' new Google Account page (https://www.google.com/accounts/NewAccount) is pretty straightforward, but not convenient at all for new users of a GAE app: no mention of anything not Google (users who don't really know what authentification is won't have any clue of why they need to open an account with Google), dead end (won't lead anywhere in the end), ugly.
GAE Log In screen includes a link to the New Google Account page. This link is of the form:
https://www.google.com/accounts/NewAccount?continue=http%3A%2F%2Fexample.com%2F_ah%2Flogin%3Fcontinue%3Dhttp%3A%2F%2Fexample.com%2Fprofile%2F&service=ah<mpl=gm&sig=0aa0a000aa000a00000aa0000a000aa
(Where example.com is the return url provided to the API). Great! But the situation is in no way different than it was: still a dead end, still no mention of any non-Google app, still ugly).
So, I'm asking, is there any imaginative way to provide a nicer interface for new users? Have anyone have ideas of how to present the process to the new users (a video for how to create a new account? some kind of tutorial page? etc.)? Just trying to think outside of the technical box here...
Regarding the various authentication options you can check out the Java or Python docs on OpenID (http://openid.net/)
Basically this allows supporting authentication by different agents, which includes Google accounts or even your own GAE application's custom implementation.
Furthermore you can check out User Experience summary for Federated Login for more information regarding UX considerations and best practices - with user authentication.
I have an App Engine web application (based on python) in which one I would like to offer a "Free" Version and a "Premium" one. I would like to charge a monthly fee to the users that want to use the Premium version of the app, blocking access to premium features to the free users, just as Grooveshark does.
Which is the best way to do this when you're using Google App Engine for developing? I mean, I know that Paypal let you to charge a monthly fee to users but, How can I restrict access between the two interfaces? I'm really lost in this field, Never made a "Paid Model App" before.
Authorization determines what your users are allowed to do in your application based on their roles/permissions.
Basically you would need the following things:
A flag membership status that indicates if a user is Premium or not; this should be set after the payment
A #is_premium decorator to check if, reading the membership flag value
, a given Web Handler can be called by the current user
Have a look to Web2py authorization, Django Auth or Tipfy acl extension for some pretty neat solutions.
I have developed a dating website built on top of the Google App Engine, to which I would like to add instant messaging, and possibly/probably audio and video conferencing.
Given that the users on the website do not want to share their personal details or real contact information, I am handling all of the login information and sessions without assuming that the clients have (or even want) a google account ID or any other login that is associated with their real identity.
I would like to hear suggestions on how I could go about adding instant messaging to my website given that I cannot just directly access Google Talk or some other existing service.
Would it make sense to use XMPP for this, and if so will Google Talk or any other XMPP service provider allow me to register new user accounts without manual intervention (ie. after a user is registered on my site, automatically register them with the XMPP provider)? Or, if not, perhaps I can use a single google ID with Google Talk with a different resource identifier for each user (me#google.com/user1, me#google.com/user2, etc...), and send messages between the different resources? Could this work, and/or would having thousands of simultaneous connections to a single account get me banned from Google Talk?
Perhaps some kind of AJAX based solution might make more sense given the fact that users are already registered on my website, but are not registered for an XMPP service?
Any suggestions about how I might approach this problem would be greatly appreciated.
Kind Regards
-Alexander
Text chat is the easier problem. You can do either with or without XMPP. Without XMPP, you'll be building a Facebook chat type client on your pages that sends messages from each user to the app, and the app then shows then on the recipient's screen.(The client can be polling, or use comet when it comes out). Check out olark to see how this works.
Once you build code to use the app as a switchboard that routes the correct message to the correct person (anonymously, maybe), you can port this easily to XMPP if you require. Both parties add you.dating.site#appspotchat.com to their buddy lists, and you send all messages from girl#site.com to guy#site.com and vice-versa. (assuming a heterogeneous site.)
Audio and video, I have no clue how to do without sharing details between the parties :-/