I have a small, dinosaur-era command line interface (CLI) app for facebook. There's not a huge user base, but it has its niche. Its most altruistic usage is by those who are partially blind and rely on other text-based command line interfaces.
It truly is a "Desktop App", with no browser interface, and no way to embed a browser within the app. It's written in PHP using the PHP CLI and it's hosted on github. [get the beta branch for the newer info].
I'm clearly a little concerned about the removal of offline_access.
I was pinning my hopes to the pending "Device Login" and was really hoping that it would be ready before they flip the switch to remove offline_access but this doesn't appear to be the case. I cannot find any information from facebook that indicates when "Device Login" will be available. I'm secretly hoping that someone on the FB Dev team will see this and hook me up as an early adopter.
Currently I send the user to the very old 'one time login' page: www.facebook.com/code_gen.php?v=1.0&api_key=XXX which gives the user a temporary authorization code, which I can use to get an older session key -- then I can use graph.facebook.com/oauth/exchange_sessions to get a new OAuth session.
So I am hoping someone at Facebook will shed light on when "device login" will appear, or if there is a better approach I should be using.
Right now, the best solution I have is to host some page that would display to the user what their oauth session information would be, and then have the user cut & paste it as a command line argument to my app. I'd like to avoid that approach -- especially because now it looks like they'll have to do that periodically (every 60 days).
As someone also commented, Facebook has offered alternatives.
https://developers.facebook.com/docs/roadmap/completed-changes/offline-access-removal
Related
I'm writing a Playwright test that starts with a Google Auth0 login. After I fill my test user and password in the UI (google login), in Firefox and Webkit the authentication passes successfully, while, on Chromium, I'm getting the Verify it's you message (with a "send sms" message).
The account does not have 2 steps authentication.
When it happened locally, I opened the browser in headful mode, and after few clicks (which I assume "told" the browser that I'm a real user) the problem disappeared (I can now run my tests in headless mode locally). But, it still happens on CI (GitHub)
I run the test with chromium flags: --disable-dev-shm-usage and --disable-web-security.
I couldn't find any data about it anywhere...
When Google determines that a user is logging in from an unknown device or a new location, they may prompt the user with an additional login challenge.
The login challenge that the user receives depends on the information that associated with the account.
Does the prompt say "Enter a phone number to get a text message" or something else like "This device isn't recognized..."
If the former I believe you can circumvent this extra prompt by having a phone number linked to the Google account in question. If the latter I believe the prompt is once per user per device.
My understanding it is basically Google trying to get a valid phone number for the account (to prevent spam etc).
-- Edit
The only other thing I can think of is that you can temporarily turn off the verify-it's-you challenge, for 10 mins, but only if the account is a member of a Google Workspace or Cloud Identity service. I am not sure this is possible for an unmanaged account - or how useful it would be. The other issue is that for "free services" Google doesn't really offer any kind of support.
Anyhow, you might try "Temporarily turn off login challenges for a user" -
https://support.google.com/a/answer/12077697
There is also so good information on this verify-it's-you challenge here.
https://workspaceupdates.googleblog.com/2018/04/more-secure-sign-in-chrome.html
It has some notes on disabling the challenge per organization via response headers, but again this is for an organization and managed accounts.
If you wish to disable the new screen for your organization, you can
use the X-GoogApps-AllowedDomains HTTP header to identify specific
domains whose users can access Google services. Users in those domains
won’t see this additional screen, as we assume those accounts are
trusted by your users. This header can be set in Chrome via the
AllowedDomainsForApps group policy.
I wrote two small Google Scripts that present simple forms to fill in. Most of my user community has no trouble using them. A small minority of users can never open the forms, instead they get "Sorry, unable to open the file at this time" error page for both forms. I can't find any common thread for why only some users fail. I've tested on multiple browsers on multiple machines, even on android devices, it never fails for me.
A couple of things I've noted:
when it fails for them the URL is re-written. The proper url starts with https://script.google.com/macros/s/... but for broken users when they paste that in they instead get https://script.google.com/macros/u/3/s/... (notice the "u/3" at the end)
There is no execution log created when they try to access the site, so I have no way to debug what's going on.
The app is permissioned so "Anyone" can access it, and it runs as my account
Sorry, I realize this problem description is impossibly vague. Any debug suggestions would be extremely welcome. I'm not a regular Google App Script developer, so I'm kinda stumbling in the dark with this one. Thanks in advance.
/u/3 means that the user have signed-in into multiple Google accounts, the number correspond to the zero-based index of the account in the order that the user followed to sign-in, 0 is for the default account, 1 is to de second account, 2 is for the thirds account and so on.
So, on your test include this use case, a user signed-in into multiple Google accounts.
NOTE: It's known that the HTML Service do not handle as expected this use case.
Related
AuthMode gets confused w/ multiple logged in users
We're sorry, a server error occurred while reading from storage. Error code PERMISSION_DENIED
Why is my script pushing an incorrect URL? [/u/2 inserted into script URL] (possible duplicate)
Is there anyway to convert or import AIML files to Dialogflow or Lex for creating a chatbot? I am hoping for a way to incorporate open source AIML files into an NLP chatbot framework like Dialogflow or Lex, and so far my googling has produced no avail.
I found a way to create a Dialogflow bot using CSV, and I wonder if this is a case of converting AIML into CSV? Is it feasible or a fool's errand?
Much appreciation for your advice, guidance, and brainstorming!
Keith Sterling has a way listed on his github page using python 3. It also has a full step-by-step implementation with screenshots and was just updated a few days ago. It’s AIML 2.1 compliant as well.
Also, it is completely free. DialogFlow itself has both free and paid tiers (as you may know) but his program is open source.
Here’s the link:Program-Y github Repo
By way of background, this is an AIML Interpreter (which is to say it is a way for you to deploy your AIML files under various circumstances). So while the link in the OP is more direct, this gives you more options.
For example this allows you to use your same files in:
Google Assistant
A Web Client
Messenger
Telegram
Alexa
Cortana
DialogFlow
etc
And because this is REST you only interact with your main implementation and this in-turn updates all client bots.
This helps you keep an updated central set of AIML files and is also lower on overhead.
Set-up:
First sign in and then click Create Agent.
Give you bot a name, and ensure the language and timezone is what you need them to be, and then click:
Create Intents
First, delete the 2 existing intents:
Default Fallback
Default Welcome
Next, create the intents for integration with Program-y (the name of the Repo).
There are 4:
Launch
Quit
Help
Query
Launch Intent
Click Create Intent
Enter your training phrases
select event, and then,
under fulfillment, choose web-hook
Quit Intent
Carry out the same steps as above, this time naming it Quit, but this time do not select an Event and use the following phrases:
stop
exit
leave
quit
Help Intent
Again carry out the same steps as above, this time naming it Help. Again do not select an Event and use the following phrases:
help
what can I ask you
help me
what can you do
Query Intent
Finally carry out the same processes, but this time name it Query. Again do not select an Event, but this time we have one training phrase
query
This time, however, add a parameter as follows:
Connect Endpoint
Finally we need to set the endpoint that DialogFlow will call each time it identifies an intent.
On the left hand side menu bar, click Fulfillment link. Click Enabled and then enter the URL that should be called which Program-Y is running on as a Google client.
The API endpoint is always /api/alexa/v1.0/ask So combine this with the ngrok URL, gives you https://87e27269.ngrok.io/api/alexa/v1.0/ask
To save this click 'Save Endpoints' and you are ready to get your client up and running.
Scroll down to the bottom and click Save.
I know that’s a lot of info and it may look overwhelming however there are screenshots and a walkthrough at the link:
Program-Y github Repo
No, currently there is no way to do this. There is no straightforward way to translate AIML files to Dialogflow or Lex JSON import formats. The basic structure of how the conversation is handled is different. Although you can find the idea of Intent, Entities and Context in AIML (specially v2.0) you would need to do a lot of manual effort to adapt it.
I would recommend extracting the patterns -what the user says- and the templates -what the chatbot responds- from AIML, import it to the framework you want to use and adapt manually the context and entities.
We currently have an implementation that uses boxes API. Our authentication process follows the process outlined here:
http://developers.box.com/get-started/#authenticating
Sometime in the recent past this has stopped working. When we go to the oauth URL (for example, https://www.box.net/api/1.0/auth/rev37d850p6pixlemm5ok8doxj2g77kg), it will initially show the login credentials page, but faster than a user could reasonably enter their credentials the page starts returning "expired ticket". If I immediately go to the token's page after creating it I can reload the page a few times before it goes into the "expired ticket" state. This is clearly not consistent with the expected 10 minute expiry time stated in the documentation.
We've had this authentication working correctly up to now, so it seems like something has changed.
We are investigating. More news once we have some additional information.
New info>> We've identified the bug, and will be pushing a fix this afternoon.
The fix has been rolled out. Please let us know if you are still experiencing any problems with SSO.
Our Android app has the same problem. As far as I investigated it, using get_auth_token API causes the ticket to expire. So you have to make sure the user has successfully logged in BEFORE attempting to get the authentication token (which is not the case with Box SDK for Android). But I don't see a viable way to check whether the user has logged in.
I am an android application developer (trying to be one) and I want to learn how to communicate with web sites from my applications. However, I don't know where to start. Can you point me in the right direction?
PS : I believe "web communcation standarts" is wrong term but i don't know how to call them.
I'd suggest that you learn by doing. Pick an idea - let's say you want to upload a picture from your Android phone to facebook.
Now go and research how to do that. Facebook exposes what they call the "Graph API" for all fb resources, including users, statuses, and photos, among other things. The Graph API is a REST API - in other words each item on the backend is modelled as a "resource" which is accessible from a URL. (Learn more about REST on wikipedia). Send a GET HTTP message to the given URL and you can get information on the resource. Send a POST to the container of that resource, and you can add another of whatever it is. In this model, to add a photo, you POST to the album URL. Read on FB for how to do that. They call it "publishing".
But reading that doc page you learn that in order to POST you need an authorization token.
Your app needs publish_stream permissions. How do you get that? Keep reading in the FB doc and you'll see a link to the Authentication and authorization guide. That tells you about how to use OAuth 2.0 in Facebook apps.
Your app will send its first feeble message out, and get an error response. Why? You'll want to examine the message. so you google and figure out that you can use an http debugging proxy to help you, something like Fiddler2 for Windows, or Charles for other systems. So you download that, set the proxy on your Android device, and now you can view outgoing HTTP messages and their responses on your PC.
Keep plugging along, learning what you need to accomplish the task in front of you: in this example, posting a photo from an android device to Facebook.
After you reach that goal, you will have learned quite a bit of practical knowledge for this domain of problem. Then you can try a new goal, and work on that.
After a few iterations of this, you will have learned how to learn, which is even better than learning REST or OAuth. If you know how to learn, the sky's the limnit.
Learn about HTTP first. There is far more to HTTP than there first appears. It is a building block for everything on the web.
You will not go wrong by getting very familiar with this http://www.w3.org/Protocols/rfc2616/rfc2616.html