I have a telegram bot and it was working without any problem since yesterday( 5/9/2018 )
but now it receives 403 when trying to download a file. I didn't see any change in Bot API documents. Even when I try to download the file manually I get 403. The problem isn't seen in my other bots.
I know the process (first making a getFile request and then generate the direct file path from file_path in the response) but when I try to download the file from generated url (https://api.telegram.org/file/bot<token>/<file_path>) it returns 403.
More Info:
I send the file by my own user to the bot, so neither the file message is deleted nor the file owner is deactivated or cleared history or somthing
It seemed that there were a bug in Telegram Service. Cause the problem disappeared a month later. I contacted telegram and ask them for the reason but I got no answer, by the way, as the problem solved without any change in my code, I think it was a bug on Telegram Service.
This is possible if the file was deleted from a dialog by user himself. In this case Telegram delete files physically from storage and throw 403 error.
I also suspect that Telegram also delete all files from dialog history if user clear history (but I'm not 100% sure in that, but it's quite logically).
If this answer doesn't help you, provide more information:
* What type of chat?
* Who sent that file (user or bot)?
Related
Like the tutorial, I deployed the tomcat server step by step, and then used postman to test the back-end login function interface, but kept reporting errors, and at the end of the terminal it printed out :
Having failed to acquire a resource, com.mchange.v2.resourcepool. BasicResourcePool#2bda742d is interrupting all Threads waiting on a resource to check out. Will try again in response to new client requests.
The complete output in the terminal in idea is:
enter image description here
the error on postman show that:
enter image description here
it was just download all the time and have no result, and I can ensure the url is right.
I will appreciate it if you can answer me.
It seems that the password of the database root account was wrong, maybe you should check your configuration file.
Linkedin has a whole slew of fields to pull them with their API. But they say they want you to apply for something before you can request the fields (see a screenshot below). My question is, can I query those fields during development to test my app? Now Linkein returns error, if I try to request them. And Linkedin doesn't say anything about it in their API docs.
InternalOAuthError: Failed to obtain request token
Here is a screenshot.
I still don't know the answer whether I can test the behavior during development.
However, with trial and error method I found what permissions generate error in Linkedin. Lol thing is that you can request fields from those permissions just fine (no error throws), but cannot request permissions.
Fields from forbidden permissions (do not throw even if permissions are omitted in a request):
['languages', 'date-of-birth', 'phone-numbers', 'im-accounts'],
Forbidden permissions that throw:
['r_fullprofile', 'r_contactinfo'],
When I send a one-off document to RightSignature via their API, I'm specifying a callback location in the XML document as specified in RightSignature's schema definition. I then get a signer-link value back from their API for the document. I display the HTML response from the signer-link URL in an iFrame on our website. When our user signs the document in this iFrame, which is rendering the responses from their website, I want their website to post to our callback location.
Can I do this with the RightSignature API and does it make sense?
So far, I'm only getting content in the iFrame that indicates that the signing was successful. The callback location does not seem to be getting called.
I got it solved just now. Basically, i was doing two things wrong first you have to go in RightSignature Account and set it there the CallBack url
Account > Settings > Advanced Settings
But the thing which RS is unable to mention to us that this url can not be of localhost, but it should be of https i mean like Live URL of your site like
https://stagingmysite.azurewebsites.net/User/CallBackFunction
And then in your CallBack just write these two lines and you will receive complete XML which would have the GUID and document status as well.
byte[] data = Request.BinaryRead(Request.TotalBytes);
string callBackXML = System.Text.Encoding.UTF8.GetString(data);
I found the answer with some help from the API team at RightSignature. I was using callback_location but what I really wanted is redirect_location. Their online documentation was difficult to follow and did not clearly point out the difference.
I got this working after a lot of trial and error.
I set up my own hosted phabricator, everything is working fine (Diffusion repo etc)
I ran into problem after I installed arcanist on my dev box and run 'arc install-certificate', got exception as following:
rying to connect to server...
LOGIN TO PHABRICATOR
Open this page in your browser and login to Phabricator if necessary:
http:///conduit/login/
Then paste the API Token on that page below.
Paste API Token from that page: cli-e644viducdcccrge4i7zo5nfa66d
Usage Exception: The token "cli-e644viducdcccrge4i7zo5nfa66d" is not a valid API Token. The server returned this response when trying to use it as a token: ERR-CONDUIT-CORE: Attempting to access attached data on PhabricatorUser (via getAwayUntil()), but the data is not actually attached. Before accessing attachable data on an object, you must load and attach it.
I am wondering what's might go wrong? Thank you very much for your insights!
I've seen this problem occur many times with our users. In every case so far, the problem has been that users have set up the phabricator uri incorrectly.
Suggestion:
Check your project .arcconfig or your global .arcrc files (if you're doing this outside a project).
Verify that the URI to your Phabricator site is correct. The typical issue I've seen is accessing using http:// rather than https://
I've created a registration system like this:
User fills in a form at /register
The form is posted to the same page (/register)
If the form is valid, the user will be added to the database with isActive = 0
A token will be generated to activate the user
The user gets an e-mail with a link containing the token
The user clicks the link and goes to /activate/{token}
If the token matches to the database, the user will be activated isActive = 1 and redirected to return $this->redirect($this->generateUrl('login')); with a flashmessage Account activated, you can login now.
Everything is working fine, over 1500 users registered in the past 2 days. But some are experiencing trouble activating their account. After clicking the link they receive a 404-error. However, their accounts are activated as supposed.
I searched the logs and found around 1500 records, more or less around the time users are activating their account: No route found for "GET /favicon.ico"
/favicon.ico doesn't exist, the favicon is located somewhere else and included in shell.html.twig, so every regular page has the favicon. But because the /activate/{token} is just redirecting, no view is loaded.
It possible this has something to do with the error some users are encoutering?
Maybe the error has nothing to do with the favicon, all suggestion are more then welcome. I'm not able to reproduce the error, so it's very hard to debug at the moment.
Also try to use different browsers to test this. You can also test this on your local machine. I have found online that some browsers (IE) automatically request /favicon.ico in some cases, if you include it somewhere or not.
Read through this for a start: How to prevent favicon.ico requests?
I see this is an old thread and you probably solved your issue years ago but here are my two cents - when I try to run a Symfony 2.3 application with one of the later php 5 versions, I get the same error message as you in my log file, it complains about the favicon.
That is however not the real issue. The real issue that caused this redirection and in turn the favicon-issue is that I am using an old version of FOS User Bundle, and there is a conflict between the user unserialization and the new php version. Move to a more recent version of FOS User Bundle and you should be ok.