I am starting to write the Asana API using Embarcadero EX6 that is using the built in REST Client. I have my RESTClient, SimpleAuthenticator, RESTRequest and RESTResponse controls in place so there isn't any code to show since it’s all done within those controls. I am not getting a “Not Authorized” return error so I think the API key and authorization is setup correctly. However I am getting the following response back when I run a query for users. The RESTRequest is using POST.
{"errors":[{"message":"Empty field name"}]}
Any ideas?
POST is (generally) for creating, so you need to specify the fields of the resource you want to create. In this case to retrieve users you want to use a GET.
Related
I would like to create a centralized user access check (token authentication for iOS / android devices) for all the APIs and return the response as JSON, if the user failed in access check. I tried _custom_access method in routing.yml and created a function in a controller to check the user permission and returned the response as "AccessResult::allowedIf(false)", when the user fails in access check. But, the "AccessResult::allowedIf(false)" returns the HTML page instead of JSON response.
Please advice if there is any best way to implement this feature in Drupal 8 code.
Thanks,
try by adding format=json to the query string of the url
I used to get the user's username in the API 1.0 fairly easily, using /me and getting the username property of the response object.
Now I'm getting this error with API 2.0:
"(#12) username is deprecated for versions v2.0 and higher"
The only way I found to get this until now was to use FQL, but now it seems deprecated.
Is there a way around this?
I don't mean to be unhelpful, but it appears access to username has been removed from the API, as far as I can tell. Places where an app may have been using username, such as in the old share dialogs, can no longer do that when used with the 2.0 API. I think its also a way of preventing apps from having access to usable unique identifiers outside of the app scope - any user IDs you retrieve under 2.0 API are specific to your app alone.
I found a simple workaround that involves a get request to Facebook. Instead of the username, Facebook will give you an ID that is unique to your application.
I have found that making a request to https://www.facebook.com/[profile_id] will then redirect to the user's real profile. The username can be extracted from the redirect URL.
Example:
> curl -i https://www.facebook.com/710290539
HTTP/1.1 301 Moved Permanently
Location: https://www.facebook.com/colinskow
(Note: Since I am the owner of the app in test mode, this could possibly be an exception. Please let me know in comments if you are able to confirm this in a production environment.)
As a workaround you can use the email as a unique identifier. Email address can be retrieved using "email" as the permission scope.
Facebook has removed the username field from the new API version. It is not possible to retrieve the username. But Facebook provides an application specific unique ID. If you need to share the same user between several apps you can use the newly introduced Business Mapping API. This allows to add all the required apps to a group. In this case the ID will be unique among all the apps in the group.
More information on Business Mapping API is available at https://developers.facebook.com/docs/apps/for-business 1
This question is derived based on Django-Rest-Framework updating a foreign key BY Id.
I have a somewhat similar problem. I love HyperlinkedModelSerializer. I could navigate through all the links of the API from my web browser (e.g. Chrome, FF, etc.) but when I try to use the API, I have a much work to do in the client app. I have no issue with the GET request. In POST request when updating a model with ForeignKey, I need to construct the URL from the client app (e.g. AngularJS, Android, etc.) before making the POST request to the server. I'm aware of the ModelSerializer which solve the problem from the client app, but it is not navigable from the web browser.
I'm not sure what is a good approach in designing browsable REST API. I'm not sure how most people solve this problem, when they want to create a browsable REST API, at the same time, they don't want to add the complexity on the client app by having to parse the URL-ID before making POST request. Or could this be just my problem that no body encounter.
Why not HyperlinkedModelSerializer does the following instead.
return all the ForeignKey in URL upon GET request. So that developer could navigate the API from their web browser.
accepting ID upon POST request. So that developer could just pass the ID rather than having to construct the full URL from the client app.
Example:
c = Client()
data = {
'user': '1',
'industry': '1'
}
c.post('http://localhost:8000/favorite_industries/', json.dumps(data), 'application/json')
response = c.get('http://localhost:8000/favorite_industries/')
print(response.content)
# [{"id": 1, "user": "http://localhost:8000/users/1/", "industry": "http://localhost:8000/industries/1/"}]
Question:
What could be the advantage from the current design of HyperlinkedModelSerializer?
What could be the drawback from my suggestion?
How can it be done?
I don't see a need to construct URLs at all. When you are sending foreign keys, you are basically referencing another object. This other object you should already know its identifier. In your example, the user id is 1. If you build your API around HyperlinkedModelSerializer, user object will come with its own identifier: url. Before creating your favorite_industries object, you need to know which user to associate with. In normal situations you will have the user object including its url:
{
"url" : "http://localhost:8000/users/1",
"name": "Yeo"
}
All you need to do is sending this identifier as a foreign key:
data = {
'user': 'http://localhost:8000/users/1',
'industry': 'http://localhost:8000/industries/1'
}
I say in normal situations because usually in your client app ids are not entered by users but other info like name are displayed for the user to pick which mandates having the full user object including its url.
I implemented a batch job which makes a webservice call within the same salesforce instance, which then is supposed to send emails with a pdf attachment,
since you cannot send pdf attachments directly from a batch job. My webservice call looks like this:
public static void callOut(List ids){
InvoiceAttachmentConnector.InvoiceAttachmentService ws = new InvoiceAttachmentConnector.InvoiceAttachmentService();
ws.SessionHeader = new InvoiceAttachmentConnector.SessionHeader_element();
ws.SessionHeader.sessionId = UserInfo.getSessionId();
ws.handleInvoicePdfAttachment(ids);
}
However in batch jobs UserInfo.getSessionId() returns null, therefore i get a INVALID_SESSION_ID exception.
How can i log in to get a SessionId? So far I found no solution to login from salesforce to salesforce. If u can help I would appreciate it! Thanks!
You cannot get a session Id like this in batch apex as it runs under the system context and so has no specific user info for retrieval.
UPDATE:
You have the following options:
Try running the web services wsdl from your Salesforce org through the wsdl to apex generator in your org to generate some classes that may allow you to login. You are only allowed one web service request per execute call.
You could create a sites page that you make a HTTP get request to in your batch apex. This needs to retrieve the Ids of the items you want to send the PDFs for and a particular user to run as for you to use the System.runAs(user) method. You could pass these parameters in the HTTPRequest header or in a custom setting.
Note that neither of these solutions are ideal, you may want to reconsider why you are using Batch apex first of all and see whether you could reimplement it in a different way.
I have a web application that needs to allow users using different webclients (browser, native mobile app, etc) to register. After signing in they can access restricted content or their own content (like entries they create, etc).
What I did so far: I created a jax-rs rest webservice (I'm hosting my application on glassfish) that exposes the following methods:
register - user POST's his desired username/password/email/etc; if username/email is unique, an entry for this user is created in the database (I'm using Hibernate for persistence)
login - user POST's username and password. If they are ok a UUID is created and returned to the user (this will be used as a token for future requests). I have a table called logedusers, with userID, token, validSince as columns.
Here is where it gets confusing for me.
Let's say that I have another method, getUserEntries, that should return all the entries made by the user. To make this clearer, there will be a Entry table with the following fields: entryId, userId, text.
What is the best approach here?
What i do now, is I make a get request and pass in the token like this:
localhost:8080/myApp/getUserEntries?token=erf34c34
Afterwards, if the token is valid, I get the userID from the logedusers table and based on that userId, get all the entries and return them as json.
Something like this:
#GET
#Path("getUserEntries")
#Produces(MediaType.APPLICATION_JSON)
public Response getUserEntries(#QueryParam("token") String token) {
String userId=getUserIdFromToken(token);
if (userId == null){
return Response.status(Response.Status.UNAUTHORIZED).build();
} else {
//get some data associated with that userId, put it in the response object and send it back
return Response.ok().entity(response).build();
}
}
However, what happens if I have more methods that provide data if they are called by a valid user?
I'd have to do this check at the beginning of every method.
I want to make this authorization process transparent
So, two major questions here:
Is this design ok? The whole authenticate with user/pass, server creates and stores and sends token to the user, user sends token on future requests.
What do I do if i have many endpoints that need to determine the identity of the calling user? Can I mark them with some annotations, use some sort of security provider / authenticator (where I can add my own logic for validating - eg check to see if the token isn't older than 5 days, etc).
Thanks
Is this design ok? The whole authenticate with user/pass, server creates and stores and sends token to the user, user sends token on future requests.
It's somewhat OK. The conceptual level isn't too bad (provided you're OK with self-registration at all) but the interface needs a lot of tweaking. While yes, POST to register and login is correct, for the rest of your webapp you should be pulling the identity information out of the context if you need it, and using role-based access control at the method level where you can.
Note that your container has a whole set of authentication and authorization-support mechanisms built in. Use them.
What do I do if i have many endpoints that need to determine the identity of the calling user? Can I mark them with some annotations, use some sort of security provider / authenticator (where I can add my own logic for validating - eg check to see if the token isn't older than 5 days, etc).
Do they need the identity? Or do they just need to know that the user is allowed to access them? If the latter, the easiest method is to put a suitable #RolesAllowed annotation on the method, at which point (with suitable configuration; see the JEE5 security docs). If the former, you need to get the HttpServletRequest object for the current action and call its getUserPrincipal() method to get the user's identity (or null if they've not logged in yet). This SO question describes how to go about getting the request object; there are a few possible ways to do it but I recommend injection via a #Resource annotation.
What I wouldn't do is allow users to normally provide their own identity via a #QueryParam; that's just wildly open to abuse. You can allow them to ask about other users that way, but then you need to decide whether you are going to tell them anything or not based on whether the current user is permitted to know anything about the other user. That's the sort of complex security problem that comes up in a real app, and is a good point for needing the current verified user identity.