Birdy (OAuth, Twitter, Tweets&MegaHAL v6.01d) Jun12,2013

[daigo]

Also getting this error:

Code: Select all

09:44:05 <@daigo> !tweet test
09:44:07 < daigobot>  You are not able to tweet in #daigo. You must have (n|n flags), or be (op voice) in #daigo. Both of which you aren't. :P

Here is my script setting:

Code: Select all

set twitter(flags) "n|n"

And my eggdrop flags:

Code: Select all

[09:44:54] #daigo# (#daigo) chattr daigo
Global flags for daigo are now +ghjlmnoptvx.
Channel flags for daigo on #daigo are now +glmnov.

I even tried setting: set twitter(flags) "-|-"
But I still get the same error.

[Nocty]

I seem to be getting an oauth error that started around when Twitter disabled SSL 3.0 due to the POODLE vulnerability.

Anyone else getting OAUTH Errors starting around 6-7PM CST starting OCT-14-2014?

[SignZ]

I seem to be getting an oauth error that started around when Twitter disabled SSL 3.0 due to the POODLE vulnerability.

Anyone else getting OAUTH Errors starting around 6-7PM CST starting OCT-14-2014?

Yup, been getting

OAuth failed: (???) error reading "sock10": software caused connection abort ( internal error )

since last night. Strangely, it sometimes is sock9, then sock10 and began at 1:15am CEST (Berlin time) with sock7.
At first I thought it's either me or the host but it looks like it's something else. :/

[NewzNZ]

I've been getting this error for about the last 48 hrs:

OAuth failed: (???) Unknown problem... No reason given...( ok )

[SignZ]

I've been getting this error for about the last 48 hrs:

OAuth failed: (???) Unknown problem... No reason given...( ok )

heh, I've seen that one in my logs for months now.

[Nocty]

Is anyone not getting these errors currently?

[johne]

per speechles himself

in twitter.tcl on mine
::http::register https 443 [list ::tls::socket -request 1 -require 0]
change that to
::http::register https 443 [list ::tls::socket -tls1 1]
make sure twitter.tcl is the last script sourced
otherwise it might break the http::register if another script does that last

I can confirm that this fixes the issue.

[SignZ]

per speechles himself

in twitter.tcl on mine
::http::register https 443 [list ::tls::socket -request 1 -require 0]
change that to
::http::register https 443 [list ::tls::socket -tls1 1]
make sure twitter.tcl is the last script sourced
otherwise it might break the http::register if another script does that last

I can confirm that this fixes the issue.

Sweet, thank you very much (also thank you, speechy!).
I also can confirm this works.

[Nocty]

Thanks for the quick response! Confirmed working.

[NewzNZ]

Working here also - thanks guys!

[Nocty]

That fix seemed to work for a while, but within 24 hours the errors return until I restart the bot. Anyone else?

[NewzNZ]

That fix seemed to work for a while, but within 24 hours the errors return until I restart the bot. Anyone else?

still working here...though I had restarted the bot directly after adding the fix for other reasons.

[Nocty]

make sure twitter.tcl is the last script sourced
otherwise it might break the http::register if another script does that last

If I have another script that uses http::register, do I need to change anything in that? I'm still getting errors having changed the lines noted.

[shadrach]

I have two eggdrops (1.8 ) both loaded with twitter script and they functioned fine before the ssl issue. I made the alteration in the code as advised and one works correctly again while the other exhibited this habit of needing to be rehashed to gain functionality again. Inspecting the config I noticed that http.tcl had been sourced twice by mistake. On removing the duplicate and ensuring the titter.tcl was sourced last and http.tcl first the problem seems to have been resolved. So check your config again and maybe remove any recently added tcls which might possibly be conflicting.

[Nocty]

On removing the duplicate and ensuring the titter.tcl was sourced last and http.tcl first the problem seems to have been resolved. So check your config again and maybe remove any recently added tcls which might possibly be conflicting.

I am not sourcing http.tcl directly in my bot configs; as far as I know this is correct practice, can anyone confirm?