I keep getting 401 when trying to login via Oauth with Twitter.
I'm using twitter_oauth-0.3.3 with oauth-0.3.6 in rails
It used to work perfectly some time ago, so after some digging, I realised it might have something to do with my timezone.
In the headers of the Twitter response, one of them is:
date:
- Sun, 11 Apr 2010 16:53:34 GMT
Even though the time is actually 17:53:34 BST
I'm assuming the request is signed using BST time, and so it fails.
Anyone had this problem / found a fix for it?
The OAuth timestamp used in the signature is in the epoch time format.
You might want to inspect the Authorization request header, check for the oauth_timestamp and check what you are sending with this helpful online tool.
The difference between your epoch time and Twitter's (which you get in the response, as you wrote) should be in the +- 300 second frame.
Hope that helps!
Well, if the time is 17:53:34 BST, then it really is 16:53:34 GMT.
So, if the oauth library you're using can't cope with the server specifying the time in a different time-zone (are you certain that's what's causing the problem) then it could be a bug in the library.
(Not very helpful, I know - I don't use ruby and haven't done any oauth development myself.) Have you tried contacting the library developer(s)?
Related
Since Friday all of our users are seeing sporadic 302s when trying to access our in-GCP IAP protected resources. Cookies are valid, and definitely being passed with the request.
This has worked for us for two years and nothing has changed here recently past standard GKE upgrades.
Since Friday we're seeing sporadic 302s from IAP (X-Goog-IAP-Generated-Response: true) as if the cookie is invalid. I can recreate this problem using a simple curl command, with my cookie stored in a file called cookie.test.
`curl -vs -b ./cookie.test https://gitlab.mydomain.com/projects/myapp.git
This succeeds maybe 1 out of 5 times. Behaviour is very recreatable. 2 out of 5 times we'll get a response from gitlab.mydomain.com and the other 3 times we'll see a 303 to accounts.google.com. Same cookie every time, all requests within a few seconds of each other.
This is causing an enormous inconvenience for our team.
Has there been a change to IAP recently that might explain this? Do you have any other reports of similar behaviour?
Folks,
I am from the IAP team at Google. Recently IAP has made some changes to the cookie name. However, this change should have been transparent to the browser users.
For people using GCP_IAAP_AUTH_TOKEN cookie name for programmatic auth, your flows will break. The documented way to send credentials in a programmatic call is to use Authorization / Proxy-Authorization header.
https://cloud.google.com/iap/docs/authentication-howto#authenticating_a_user_account
Cookies are meant to be used for browser flows only and IAP holds complete control of the naming and format of the cookie. If you continue to use cookies to send in credentials to IAP (by reverse engineering the new format), you run a risk of being broken again by future changes in cookie name/format.
One clarification is required though. In the original post, it was mentioned that you are getting a response of 302 to accounts.google.com, is that true for browser flows also? If so, please respond back with a har file and I'll be happy to take a look.
cheers.
I have also started facing this issue since last week and have spent around 2 days troubleshooting it as initially we thought that it must be some problem on our side.
Good to know that I am not the only one facing it.
Would really appreciate some updates from Google Around it.
However, one thing I found:- There was one official blog from google around IAP:- https://cloud.google.com/blog/products/identity-security/getting-started-with-cloud-identity-aware-proxy
they have updated this blog on 19th January and removed the mention of the cookie:- GCP_IAAP_AUTH_TOKEN
However, the line they have changed is still unclear to me and very confusing
It now says :-
That token can come from either a browser cookie or, for programmatic
access, from an Authorization: bearer header.
From where will the browser cookie come, what will be its name, there is no mention around it.
Let me know if someone finds a way to get it work again.
Thanks,
Nishant Shah
Yesterday (December 16, 2020), I noticed that the findMeetingTimes endpoint started returning an empty response object (when testing using Graph Explorer) for requests that would previously result in some meetingTimeSuggestions.
I've been using this endpoint for a while and haven't changed how I interact with it.
Example:
{"attendees":[{"emailAddress":{"address":"<EMAIL>"},"type":"Required"}],"timeConstraint":{"timeslots":[{"start":{"dateTime":"2020-12-19T21:52:35.093Z","timeZone":"Pacific Standard Time"},"end":{"dateTime":"2020-12-26T21:52:35.093Z","timeZone":"Pacific Standard Time"}}]},"meetingDuration":"PT1H"}
Looking at the "Find meeting times" documentation, I'm not seeing any major changes to the API (and the reference was last updated over a month ago).
Any ideas on what might be going on?
I've checked StackOverflow, the "Known issues with Microsoft Graph" page, and Twitter, and I've also done some Googling but haven't found much on this.
It's actually not empty, it's even weirder. It started aggressively returning a gzip encoded body (violation of RFC) and ignoring Accept-Encoding header (NB: If you don't put "Accept-Encoding: gzip" it won't event say Content-Encoding:gzip but it is!)
I don't know how one can log an API bug, and tho I just paid for a "support package" it didn't apparently go through yet. So I'm going to hack my back-end to detect the gzip magic bytes ( 1f 8b ) and gunzip it.
I have been using this msn weather api for couple of years now
Programatically access weather info
As of today I get the following error in my app. Access Denied. It could be a glitch or a permanent shutdown by microsoft. I don't know but is there any other free 4 day weather forecast api that I can use to get weather in a XML format? Saddest part is that I have been using this api in at least 20 of my apps and now I am scrambling to find a solution.
I did send an email to weather#microsoft.com couple of hours ago but as predicted no response.
2014-12-10 07:46:40.321 Big Clock[10890:230027] locationStr: http://weather.service.msn.com/data.aspx?weadegreetype=F&culture=en-US&weasearchstr=Detroit,MI
2014-12-10 07:46:40.461 Big Clock[10890:230027] XML:
<?xml version="1.0" encoding="utf-8"?><weatherdata xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><weather errormessage="Access denied: Please contact weather#microsoft.com if you need access to this API." /></weatherdata>
You are not alone in this.
For the time being, passing an additional query string "&src=outlook" worked for me.
Sample Working URL:
http://weather.service.msn.com/data.aspx?weasearchstr=45236&culture=en-US&weadegreetype=F&src=outlook
Try it out and see if it solves your issue.
This is Ram from Microsoft. The existing service will be deprecated soon.
Please resend your email to the alias one more time so we can take it offline. We had an email hiccup so the alias should work now.
Please do not use the outlook as src value.
We are writing to notify you that the Microsoft Weather API will no longer be available for download and will be discontinued as of April 15, 2015, meaning it will no longer provide weather data. Accordingly, please remove the Microsoft Weather API from any of your products or apps that currently use it.
Here is a list of external providers who might be able to support your needs if you are interested in obtaining an alternate weather API:
http://api.accuweather.com/
http://www.wunderground.com/weather/api/d/pricing.html?MR=1
https://developer.forecast.io/
Disclaimer: Microsoft and Microsoft Weather are not affiliated or associated with any of the above companies in any way.
Thank You
Microsoft Weather Team
Thanks to Ram we now know that MSN weather api will be gone by April 15th, 2015.
If anyone wants a free weather alternate then try this
http://openweathermap.org/price_detailes
Calls per minute (no more than) 3,000
Calls per day (no more than) 4,000,000
This is the most I have seen any weather provide give out for free. I hope it helps.
I've an API which uses oAuth for authentication.
Everything has been working smoothly for months until last week, when I started noticing oAuth was throwing 400 errors due to a Expired timestamp, yours X, ours Y.
I'm guessing that some changes on server (it's a shared hosting machine) reset or messed something with the local time.
I can't figure out any other reason, but I'd like to know if there's any other debuggin' technique that may help me.
PS: Using PHP 5.2 and the oAuth 1.0a php implementation
The OAuth server should always use UTC time as the basis for checking timestamps. Assuming that you send the correct timestamp based on UTC, check the 'ours' timestamp has the correct time in UTC. If not then its most likely there is a problem with the server time or the OAuth timestamp calculation on the server.
I am getting a '303 See Other' error when I'm placing a call to provide a specific grade value for a particular user.
PUT /d2l/api/le/(D2LVERSION: version)/(D2LID: orgUnitId)/grades/(D2LID: gradeObjectId)/values/(D2LID: userId))
All the values are valid (I'd get a 404 error otherwise). Interestingly, the call works for some courses, but not for others. Any ideas?
We've used Fiddler to track the request and the request is in the format (replaced sensitive information with '...'):
PUT https://carmen.osu.edu/d2l/api/le/1.0/.../grades/.../values/947067?x_a= ...&x_b=-...&x_d=...&x_c=...&x_t=1374779761
HTTP/1.1
Content-Type: application/json
Host: carmen.osu.edu
Content-Length: 44
Expect: 100-continue
{"GradeObjectType":1,"PointsNumerator":30.0}
The response was:
HTTP/1.1 303 See other
Cache-Control: private
Content-Length: 0
Location: /d2l/error/500
Server: Microsoft-IIS/7.5
X-XSS-Protection: 0
X-Powered-By: ASP.NET
Date: Thu, 25 Jul 2013 19:16:40 GMT
Edit: We've discovered that if a grade value is already entered, the above PUT calls works fine. It only gives us a 303 when the grade value is at the default value. This only happens in this course (that we know of).
This sounds a lot like a known issue that the Grades APIs have had in the recent past that I believe has been addressed. The fix for this issue was distributed with the May and June service pack releases. The fixed issue was resolved and described this way:
Cases which previously permitted dividing by zero in the Valence Learning Framework API for Grades are no longer permitted. This issue was fixed in Learning Suite 10.2 Service Pack 1, Learning Suite 10.1 Service Pack 8, Learning Suite 10 Service Pack 12 and Learning Suite 9.4.1 Service Pack 17.
Please verify that your LMS has been updated to at least the listed service pack level:
If it has not, then updating to that service pack level may address your issue.
If updating does not address your issue (or your LMS is already at that patch level), then you should open a support incident with Desire2Learn's support desk, and characterize the incident with them as a possible defect with the LE Assessments components. If you do that, you should also provide the URL to this question on Stack so that the support desk knows you've done some investigation into this issue already.
Workaround. There is a workaround for this issue, but it may not be feasible for you, depending upon your use case. If you enter a grade for a user first through the Web UI, then (if this is the known, fixed issue I believe it to be) updating that grade through the APIs should work -- this issue only applied when the first attempt to set a grade value was performed through the API (and, I believe, also only with Numeric grade types).