Our OAuth module worked perfectly until last week. We know Uber changed the terms of its API and we've been unable to access the server since then.
We've tried creating a different Dev account, contacting the Uber dev team, tweeting them, reached out to people internally who pointed us to stack overflow, we've filled the automated form requesting for our access to be maintained, ...
Our swift code where we fetch the Uber API data
let datafetcher = UberDataFetch(oauth2: self.oauth2)
self.uber.products = try! datafetcher.getProductData(data: self.uber)
Our error message
[Debug] OAuth2: Starting authorization
[Debug] OAuth2: Have an apparently unexpired access token
[Debug] OAuth2: Storing tokens to keychain
[Debug] OAuth2: Initialization finished
Fatal error: Unexpectedly found nil while implicitly unwrapping an Optional value
Uber is currently changing their API access, it killed many applications, mine included, somehow users that were logged in can still use it like normal, but log in has become impossible for whatever reason, so new users can't use my app, or old users that logged out. I also tried contacting in every channel possible like you, no response anywhere too.
Related
I am trying to use the NetSuite SuiteTalk REST Web Services to access NetSuite CRM data.
I have the access up and working in production. Able to retrieve record data and metadata.
I am now trying to set up access in the sandbox for more in-depth testing.
In the sandbox I have:
- Enabled rest web services
- Enabled token based authentication
- Given user concurrent web services permission
- Given user Log in using access tokens permission
- Created an integration
- Created an access token
All of these actions mirrored what was done in production.
When I attempt any kind of GET to the web service, I receive a 401 - Invalid login attempt.
When I check the Login Audit Trail, I don't see any record of the GET attempt, failed or otherwise.
Is there something of a systemic nature that I have to do additionally in the sandbox to enable rest web services? Above and beyond enabling it in SuiteCloud/SuiteTalk?
The fact that I see absolutely nothing in the audit trail makes me believe that something is still "turned off".
===> 4/4/2020 Update
ed14 and Nihkil,
Thank you for your responses, and sorry for the delay in responding back.
The hyphen to underscore in the realm did not help me unfortunately.
Let me recap recent attempts:
1) Started by verifying that REST API testing in production still works.
2) The sandbox was refreshed by a CRM admin. The application was still there, but my access token was not. I created a new one in the sandbox.
Is it possible to delete the application? I cannot see any way to do that.
3) Tested with existing Consumer Token and new Access Token. Got the same response as from my first post: "title": "Invalid login attempt, for more details see Login Audit Trail.",
4) Tested by slightly modifying the URL to make sure I was not going to a black hole somewhere. It gave me the expected error.
5) Tested by modifying the realm: Realm 9999999-sb4 to Realm 9999999_sb4 It gave me an error which leads me to believe that my original realm is correct: "title": "An unexpected error occurred. Error ID: k8hd8pqej3unxblmaoik",
Again, none of the tests show up in anywhere in the audit log as a failed attempt.
Not sure where to go from here? Delete the sandbox application (if possible) and start again? Or new application in sandbox?
Thanks for any and all help.
Bryan Hunt
I had the same issue using the sandbox. Apparently there is a mismatch between the account ID (used in realm authorization) and the account ID in the URL.
The account ID (realm): XXXXX_SB1
The account ID in the url: XXXXX-SB1
The SB should be in upper case.
This solved the problem for me.
As #ed14n and #nikhil-abraham said, changing - to _ in authorization realm and put the SB in UPPER CASE solve this problem here.
If you are using POSTMAN template provided from NetSuite, your envs should be like the image below.
In Postman in your request tab and then in the authorization tab in the advanced section there is a field called Realm. Put the account id in the realm field with underscores.
I'm prototyping a trip experience. In debug we have a button that requests an in_progress ride to work with. Everything seems to work ok.
However, a release build (hitting the real API rather than sandbox) I get no trips back.
We have requested: request and all_trips scope.
We have the test users' uber accounts added to the developer portal.
Requesting the scopes is working, we're takin to the site and it asks for the appropriate scopes, the app is listed in the user's profile.
Any ideas? Is there a region limitation, for example?
Could you provide some more details on the the exact flow you are following and what endpoints you are hitting?
If you make a GET request to nonsandbox /v1/requests/current with an access token for a user that is on a trip, what response do you get back?
I face a problem today regarding the connectivity with Orion public instance #http://orion.lab.fi-ware.org:1026/ngsi10/contextEntities/{entity_id}. While, two days ago, I got always connection to the orion public instance, always by using the same Authentication Token, I got from FI-WARE, Today when I'm trying to connect I get an error: "GET http://orion.lab.fi-ware.org:1026/ngsi10/contextEntities/urn:smartsantander:testbed:3337 returned a response status of 401 Unauthorized".
I was and continue to use the Jersey REST API so as to connect with NGS10 Orion REST API Implementation.
Is there any idea about what I have to do to solve the problem? Is this a problem in Orion Server side with the Authentication Service?
Thank you in advance!
Probably the token has expired. You can re-generated a fresh token runing the token_script.sh script, as described in the following document.
EDIT: the normal behaviour of the system is to cancel the token from time to time, so the best approach is regenerate it with a given periodicity (e.g. 24 hours). However, note that although you can manually regenerate the token and recofigure your application to use the new one as described above, it is better to program your application to do it automatically.
Please, have a look to the OAuth course in FI-WARE education platform and the Refresh Token section in the OAuth 2.0 RFC for more information.
In the .NetAggCatSample app, I've found that calling getInstitutions with an existing user context seems to work fine, but for new users, I'm getting an exceptions (message = "forbidden").
Could this be due to running into the max user limit in Dev mode (which I am in)?
Also, which API call actually creates the user at Intuit?
To add the answer,
Any API call after retrieving OAuth tokens from the SAML assertion will create the user in the system. As you mentioned, you are most likely getting the 403 error because you are at your max customer limit. Please enable logging and post the response XML from the call that returns a 403:
http://docs.developer.intuit.com/0020_Aggregation_Categorization_Apps/DevKits/0250.NET_AggCat_DevKit_1.0/0006_Logging#Request_and_Response_Log
thanks
Jarred
My application, created today, runs fine when I use it with my account. On any other account however, the following error is sent back as a response:
message: "(#298) You must be a developer of the application"
type: "OAuthException"
The exact code I'm using to send the request is this:
FB.api('/me/threads', {limit: 1000}, function(response){ ....
I have found someone experiencing the same problem, but the response he accepted didn't really provide any useful information. ( Reading over inbox, I get error #298).
Anyone have a clue on how to solve this? Would be greatly appreciated!
I'm guessing you have the read_mailbox permission?
Try accessing the /me/inbox connection instead?
Facebook tells you (from http://developers.facebook.com/docs/reference/api/thread/):
Please note: We are in the process of making the new messages system
available to all users, at which point this API will replace the
/inbox/ Graph API endpoint. We are providing early access to this API
for registered developer accounts only until the new messaging system
is broadly available. You should use the /inbox endpoint for
production applications at the current time.
That is, only the current apps developers will be able to use the threads-connection for now (but it will be available later).
It looks like your other account doesn't have a developer license/flag/attribute, thus failing the authentication check.