Vimeo implemented OAuth support on their end, the announcement was made here.
Seems like the old web authentication methods are already marked as deprecated, however they still work 4 days later. The deprecated methods are
- vimeo.auth.checkToken
- vimeo.auth.getFrob
- vimeo.auth.getToken
The new OAuth specific URLs are (Twitter alike):
Request Token: http://vimeo.com/oauth/request_token
User Authorization: http://vimeo.com/oauth/authorize
Access Token: http://vimeo.com/oauth/access_token
I noticed a big similarity between Vimeo’s and Flickr’s authentication API, and probably Flickr will do a switch soon as well, there’s no OAuth implementation on their end at the moment.
A thing I noticed is that the Vimeo API now requires the OAuth specific data and valid tokens which kind of forces everyone to switch to the OAuth tokens, instead of the old ones extracted via the deprecated methods.
Loopthing needs an unexpected code update because of this right after launching the authentication feature on our end last week, but I’m happy security has been tightened around the video hosting service.
Update: The OAuth specific URLs for Vimeo does not support SSL because of the improper setup of the certificate and the weird redirects. In the best case you’ll get a 401 error with the message “Invalid nonce”.
apis, oauth, video hosting, vimeo, web development
Initially, I’ve thought this is something that is done by bing.com haters, but it seems the HTTP referrer SPAM made for bing’s benefit is done from IPs belonging to the Microsoft corporation. The apache logs don’t lie:
65.55.104.61 – Referrer: http://www.bing.com/search?q=month (using IE 6)
65.55.104.64 – Referrer: http://www.bing.com/search?q=month (IE6)
… and so on, for 30 more times in a weekend
Now, try a whois for these IP addresses, like so.
I’ve noticed this two weeks after bing was launched and I’m not sure how legit this is from Microsoft’s side.
65.55.104.61, bing, bing.com, http referrer spam, microsoft, search engines, spam
Summer is coming and the weather is hot, why not have a look at these particular links here:
Of course, if you have any suggestions for next half-geek links round, please leave a note.
axigen, bullshit generator, damien mulley, Half-geek Links, journalspace, viral dancing, yahoo address book api
Subversion is a great tool, but sometimes because of the operating system where it runs on, you may get some nasty errors.
A good example could be the one that happened to me recently while I was trying to merge two different branches in the same repository. I’d share this with the hope that will help somebody save some time and avoid unnecessary headaches.
The error I’ve got was referring to a file inside my repository right when I was trying to commit the merged result:
Can’t open file ‘/path/to/file’: Permission denied
After some time trying to figure out what’s wrong, I’ve quit playing with permissions I’ve found the solution: changing the permissions of the whole repository files’ to 777.
Since this is not a shared environment, the settings will do just fine and you’re ready to go.
branch merging, errors, permission denied, subversion, svn, svn merge
Here’s a funny remark…
Mashable comes with this phishing warning about not clicking links on facebook pointing to some indian domain (ponbon.in – do not visit it) because they may mess things, people comment and provide information about other similar domains as well (including 151.im – do not visit it).
Half an hour later, Techcrunch comes up with a similar facebook phishing article, on the same topic but this time refering to 151.im. This is fun, and I have the feeling of reading the same publication, or maybe I am.
While I understand the importance of having my facebook account safe, I have found this half an hour difference very funny. Good for us though: the difference between posts could have been 40 minutes, geesh!
151.im, facebook, mashable, phishing, ponbon.in, techcrunch
…is a text in Romanian, and seems to be the user agent of a vulnerability scanning spider looking for an exploit specific to Roundcube Webmail service. You will notice this scanner checking the following addresses on your server:
- /bin/msgimport
- /webmail/bin/msgimport
- /roundcube/bin/msgimport
- /mail/bin/msgimport
The IP addresses of this vulnerability spider, detected by Jeromakay.com so far are:
- 82.103.131.247 (Denmark)
- 62.111.225.232 (Poland)
I’ve seen some other reports on the activity of this spider:
- Johann reported it here: http://johannburkard.de/blog/www/spam/effective-spam-bot-blocking.html (he reports requests coming from a different IP though: 85.239.254.57, in Czech Republic)
- Dmitry caught it checking for a login page here: http://dmitry-dulepov.com/article/toata-dragostea-mea-pentru-diavola.html (different IP here as well: 213.21.217.206, in Latvia)
- David posted about it on a forum: http://www.howtoforge.com/forums/showthread.php?p=161507 (ip used there by this scanner: 82.79.77.84, in Romania)
Based on this report here, other IPs used by this scanner are: 202.210.181.209 (Japan), 84.19.184.49 (Germany), 217.160.111.160 (Germany) and 114.141.15.22 (South Korea).
Seems like this malicious spider has ben placed on servers mostly from eastern Europe. Translation of the user agent is “All my love for the devil” (refering to a female devil).
exploit, malicious, toata dragostea mea pentru diavola, user agent, vulnerability
