I am new to rest api in meteorjs. I am trying to run the example explained in The meteor chef but getting this error:
ReferenceError: APIKeys is not defined
at Object.API.authentication (api/config/api.js:4:19)
at Object.API.connection (api/config/api.js:16:34)
at Object.API.handleRequest (api/config/api.js:28:26)
at [object Object].Router.route.where (api/pizza.js:9:9)
at boundNext (packages/iron_middleware-stack/lib/middleware_stack.js:251:1)
at runWithEnvironment (packages/meteor/dynamics_nodejs.js:110:1)
at packages/meteor/dynamics_nodejs.js:123:1
at [object Object].urlencodedParser (/Users/mac/.meteor/packages/iron_router/.1.0.12.13720an++os+web.browser+web.cordova/npm/node_modules/body-parser/lib/types/urlencoded.js:84:40)
at packages/iron_router/lib/router.js:277:1
at [object Object]._.extend.withValue (packages/meteor/dynamics_nodejs.js:56:1)
The code is same as explained in the example
It is because you didn't created APIKeys mongo collection as shown here: https://github.com/themeteorchef/writing-an-api/blob/master/code/collections/api-keys.js
Add this file to your project and then it'll work.
Here is explanation from post you linked:
Next, we try to insert a new key for our user into the APIKeys collection. Wait a minute! Where did this come from?! This collection was setup beforehand, but let’s talk about why we have a separate collection to begin with. The reason we want to separate our API key storage from the more predictable location of our user’s profile (the writable portion of a user’s record in the Meteor.users() collection) is that by default, the profile object is writable.
So you just missed this part of tutorial where they created APIKeys collection.
Related
When writing a CKAN extension, I can create a custom GET-able method, which automatically receives the context.
e.g.
#side_effect_free
def custom_method(context, data_dict):
# Do something with the context and/or data_dict
The context argument above, which is basically injected by CKAN, contains, among other things, the user object which can be used to identify the user.
In other cases, like for example in a template helper, how can I get access to the user information? Ideally, I would like to have a context object just as above, so that I can call for example package_search and the rest of the actions provided in the toolkit.
Turns out that when calling actions, skipping the context variable will cause ckan to add it later inside the call, so there's no need to provide the context yourself. Also, if you want information on the user, the g variable from Flask has everything you need.
Modifying Piranha for 'headless' scenario: I separated the api into its own REST API, and the MVC into its own UI that calls the REST API. Mostly it works well, but now an obstacle. My REST API serializes the result from the Piranha api, and my MVC web deserializes it into a Piranha StandardPage type. This works for all fields except Media, which is always null. Using newtonsoft.Json.
The Media property is defined in Piranha.Extend.Fields.MediaFieldBase with internal set, which explains why I can't deserialize into it. So I added a [JsonProperty] attribute to the Media property. Once I did this, then the Media field was correctly deserialized by the MVC, and images appeared.
But then I found this broke something else: in the manager, when I try to save a page with a Hero image, the Save buttons spins, stops as though it succeeded, but the toast never appears saying success. I set Debug logging for Microsoft.AspNetCore.Mvc.Infrastructure, and see there's a model state error when this happens:
dbug: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[2]
Executed controller factory for controller Piranha.JA.Manager.Controllers.PageApiController (Piranha.JA.Manager)
dbug: Microsoft.AspNetCore.Mvc.Infrastructure.ModelStateInvalidFilter[1]
The request has model state errors, returning an error response.
dbug: Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker[3]
Request was short circuited at action filter 'Microsoft.AspNetCore.Mvc.Infrastructure.ModelStateInvalidFilter'.
I can debug into the PageApiController for most operations, but when Save executes none of the breakpoints are hit.
I also tried just removing the internal accessor from set (and removing [JsonProperty]) and got the same behavior: can deserialize Media ok but trying to save page with a Hero from manager gives model state error.
Would love to write up some documentation on how to go headless if we can solve this.
We've been debugging this one for a few days, can anyone help?
In the branch I pushed I actually changed the accessor to public, so you shouldn’t need the additional attribute. This is also merged to master and will be released in 8.3.
Regards
I posted this on the Piranha CMS github and one of its authors, Hakan Edling, answered in just a few hours:
"The root issue is that when a new item is selected in the manager in the media picker, the media model that is assigned contains a formatted string size "xxx kb". When ASP.NET tries to deserialize this into a long it fails.
So changing the following line in the .vue components for the media-based fields:
this.model.media = media;
to
this.model.media = {
id: media.id,
folderId: media.folderId,
type: media.type,
filename: media.filename,
contentType: media.contentType,
publicUrl: media.publicUrl,
};
Resolves the serialization error in the manager when the Media property is public.. I'll push this fix to a new branch so you can test it."
And soon after,
"Please test with the branch https://github.com/PiranhaCMS/piranha.core/tree/features/make-mediafield-media-public"
I still must add the [JsonProperty] attribute to the Media field in MediaFieldBase class, so my deserializer can access the internal set method. Hakan's fix makes it so this attribute doesn't break the manager.
Thank you for your quick response Hakan, you rock!
currently the JSONStore API provides a load() method that says in the documentation:
This function always stores whatever it gets back from the adapter. If
the data exists, it is duplicated in the collection". This means that
if you want to avoid duplicates by calling load() on an already
populated collection, you need to empty or drop the collection before.
But if you want to be able to keep the elements you already have in
the collection in case there is no more connectivity and your
application goes for offline mode, you also need to keep track of
these existing elements.
Since the API doesn't provide a "overwrite" option that would replace the existing elements in case the call to the adapter succeeds, I'm wondering what kind of logic should be put in place in order to manage both offline availability of data and capability to refresh at any time? It is not that obvious to manage all the failure cases by nesting the JS code due to the promises...
Thanks for your advices!
One approach to achieve this:
Use enhance to create your own load method (i.e. loadAndOverwrite). You should have access to the all the variables kept inside an JSONStore instance (collection name, adapter name, adapter load procedure name, etc. -- you will probably use those variables in the invokeProcedure step below).
Call push to make sure there are no local changes.
Call invokeProcedure to get data, all the variables you need should be provided in the context of enhance.
Find if the document already exists and then remove it. Use {push: false} so JSONStore won't track that change.
Use add to add the new/updated document. Use {push: false} so JSONStore won't track that change.
Alternatively, if the document exists you can use replace to update it.
Alternatively, you can use removeCollection and call load again to refresh the data.
There's an example that shows how to use all those API calls here.
Regarding promises, read this from InfoCenter and this from HTML5Rocks. Google can provide more information.
We have implemented a class called AuthorizerImpl that contains two objects: an AuthorizingRealm and a Subject. We have implemented an isPermitted() method which subsequently calls the isPermitted() method on the subject. Our code looks something like this:
// UserContext object uc is passed in here
AuthorizerImpl auth = new AuthorizerImpl(uc.getUser());
auth.isPermitted("winnebago:drive:eagle5");
We initially log in and authenticate a user's permissions using the above code. The first time a user logs in, it is a a "base user" so to speak. There are certain screens that are specific to certain users, so we call the above code again with a different uc.getUser() to verify the new users permissions. What I am seeing though is that the backend Shiro code is using the previous user to check the permissions, not the new user that I passed into the isPermitted() method. Each time we are calling "new AuthorizerImpl(uc.getUser())" we are creating a new Subject and AuthorizingRealm that are instance variables inside the AuthorizingRealm object. It was my impression that when I create a new AuthorizerImpl, it should use the new subject and realm that we are creating in the constructor. However, it seems that Shiro is caching the previous realm object that was used and is using that? We are using the DefaultSecurityManager. After doing some debugging, I noticed that the DefaultSecurityManager has an authorizer instance variable. It appears to be using the first authorizer object and not the new one that should be created with the new user, which leads me to believe it is is being cached. Is there a way to turn off this caching? Is this what is happening or is it something else? The permissions are being retrieved correctly from the database if the correct user is used to check. How can I resolve this?
Thank you in advance.
I am new to Restful concept and have to design a simple API for a media analysis service I need to set up, to perform various tasks, e.g. face analysis, region detection, etc. on uploaded images and video.
Outline of my initial design is as follows:
Client POSTs a configuration XML file to http://manalysis.com/facerecognition. This creates a profile that can be used for multiple analysis sessions. Response XML includes a ProfileID to refer to this profile. Clients can skip this step to use the default config parameters
Client POSTs video data to be analyzed to http://manalysis.com/facerecognition (with ProfileID as a parameter, if it's set up). This creates an analysis session. Return XML has the SessionID.
Client can send a GET to http://manalysis.com/facerecognition/SessionID to receive the status of the session.
Am I on the right track? Specifically, I have the following questions:
Should I include facerecognition in the URL? Roy Fielding says that "a REST API must not define fixed resource names or hierarchies" Is this an instance of that mistake?
The analysis results can either be returned to the client in one large XML file or when each event is detected. How should I tell the analysis engine where to return the results?
Should I explicitly delete a profile when analysis is done, through a DELETE call?
Thanks,
C
You can fix the entry point url,
GET /facerecognition
<FaceRecognitionService>
<Profiles href="/facerecognition/profiles"/>
<AnalysisRequests href="/facerecognition/analysisrequests"/>
</FaceRecognitionService>
Create a new profile by posting the XML profile to the URL in the href attribute of the Profiles element
POST /facerecognition/profiles
201 - Created
Location: /facerecognition/profile/33
Initiate the analysis by creating a new Analysis Request. I would avoid using the term session as it is too generic and has lots of negative associations in the REST world.
POST /facerecognition/analysisrequests?profileId=33
201 - Created
Location: /facerecognition/analysisrequest/2103
Check the status of the process
GET /facerecognition/analysisrequest/2103
<AnalysisRequest>
<Status>Processing</Status>
<Cancel Method="DELETE" href="/facerecognition/analysisrequest/2103" />
</AnalysisRequest>
when the processing has finished, the same GET could return
<AnalysisRequest>
<Status>Completed</Status>
<Results href="/facerecognition/analysisrequest/2103/results" />
</AnalysisRequest>
The specific URLs that I have chosen are relatively arbitrary, you can use whatever is the clearest to you.