I'm not sure how to create a custom matcher that would verify the information stored in a custom exception. I need a custom matcher because the way exceptions are stored in this system that I'm working on is they are added up on a list. Now I need to verify that errors on that list and the error message.
I'm pretty sure this was already done before, I'm just not sure where to look for it
Try using sameBeanAs matcher from shazamcrest. It is able to compare two objects by serializing their fields to JSON. No getters, public fields or any annotations on the production class are needed. All you need to do is just create the expected object and compare it against actual object:
com.shazam.shazamcrest.MatcherAssert.assertThat(actualException, is(sameBeanAs(expectedException))
Note: it is important that you use MatcherAssert from shazamcrest and not from hamcrest, otherwise sameBeanAs gives bad diagnostics.
I am not sure how comparing exceptions will work in regards to stack trace which is just a field in Throwable. If it is a problem you may have to ignore specific fields when using sameBeanAs.
If you still want to write your own hamcrest matcher, here is the tutorial.
Related
How would one use Django DestroyAPIView and DetailAPIView and still maintain generally accepted practices of RESTfulness?
If I understand REST correctly it should work as follow (only one example)
/api/game/222
then 1 view class(generics.DetailAPIView) or method, in Django would be created to handle the call
In a REST world, I believe we would use a generic API class to handle the
methods (get,...)
But if I wanted to use the class(generics.DestroyAPIView) to handle the calls to delete a game.
then I would have to use
/api/game/delete/222
to send the request to the correct view.
It seems to me this is not consistent with RESTFULness.
for the delete method of the HTTP should be used to send the delete request and use the same pattern matching /apt/game/222 to delete the game. It's redundant.
Question: Am I missing something?
In summary
option 1:
/api/game/delete/222 (DestroyAPIView)
/api/game/detail/222 (DetailAPIView)
option 2
/api/game/222 (RetrieveDestroyAPIView)
I guess either way works, and as long as it's clear and consistent as stated below. There is no "right" way.
I not sure 'RESTFULness' affect what you are asking here. It is perfectly fine to have different matching pattern as long as it make sense.
In the example given, usually we do not have /api/game/222 as a generics.ListCreateAPIView. This is because List return a list of all game, we do not pass a id in. Create is trying to create a new Game. You do not have id yet because it is not in database, therefore both of the matching pattern should usually be /api/game/ instead.
/api/game/222 - such pattern, we usually use for generics.RetrieveUpdateDestroyAPIView because with a given id in url, we can get the correct Game object to either retrieve, update or delete it.
Regarding the Restful API, the answers in this stack overflow question explain more about 'Restfulness'.
How can I perform sanitization on string attributes to prevent XSS? Right now my thoughts are to override my base model's save method and iterate over all the strings in the model and set all the string inputs to safe strings. Would this be a good way to approach this problem or is there a better way?
EDIT:
Problem occurs when saving a name attribute ( alert('xss')) for a person in the app. It saves it in a non-sanitized manner into the database. Then that name is loaded in our other site which does not sanitize the output and that's where the script injection occurs! I'd like to sanitize it before saving it to the DB
Handlebars automatically sanitizes strings. If you want to avoid this, you must explicitly use the triple-brace syntax:
{{{myHtmlString}}}
Rather than trying to sanitise the input, you really ought to change that other site to make sure it html-escapes the data it is presenting from the database. Even if you would "sanitise" things on the Ember side, can you guarantee there are no other vulnerabilities which allow someone to inject HTML in the database?
Always escaping anything being presented is really the only safe way to deal with XSS. If you're filtering input you are very likely to not catch every possible way of injecting unexpected input.
I am currently in the process of writing a custom DataProvider. Using the Intergrate External Data documentation.
I've managed to show the external data in the Sitecore back end. However whenever I try to view the data in the items I created, I am getting an error
Null ids are not allowed. <br> Parameter name: displayName
There seems to be precious little on the subject on how to create a custom DataProvider on the Sitecore Developer Network.
The example on their website seems to only show how to import a SINGLE item into a static database. However I am simply trying to merge some items into the hierarchy and I can't find any useful documentation.
It seems that one of your methods that should return an ID doesn't. It might be GetChildIds and/or GetParentId.
Nick Wesselman wrote a good article about it gathering all the information including an example on the Marketplace. I think that is your best start. You can read it here.
Turns out I needed to include at the very least, the Fields->Section->Template in the GetParent method. To be on the safe side I included the Fields/Sections/Templates into my implementations of
GetChildIDs
GetItemDefinition
GetParentID
It wasn't obvious that this was the case, since I had in fact implemented the GetTemplates method correctly, and I had expected that should be enough.
I know that in django integration, it is easy to test if a page would load successfully by making sure status code is 200. However, the project I am working on have pages that might partially load (certain sections of the page will silently fail to load). What is the best way to catch this situation? Is there a way to insert such error into the http response?
I know I can potentially do regex on the text on the page to check for things that might not load or I can probably check that name of certain css class exist. But that does not seem to be too robust an approach.
This will greatly depend on your implementation details, but there are two suitable approaches to testing templates that may help you:
If the partial page loading can be tested/triggered by using nothing more than template syntax, create test templates that conditionally print some text you can match against in the response, such as WORKED or FOO.
If it's something that largely depends upon the context the template receives, then one-off test views, which you define alongside your test case and call directly by passing in a mocked request, work as well. In this case, you'll likely rely on the test view to raise exceptions if the page rendering won't proceed as expected, otherwise everything went well.
Alternatively, you can even mix the two. In this case, you'll rely on the view to generate a HTTP response which you'll then check for some test text.
If that doesn't work, you can resort to overriding the templates. The general problem is that you can't rely on matching against text because it's global. The template can change and potentially cause your tests to misfire. What you can then do is have specific test settings that add additional directories for template discovery where you can provide different template implementations which contain text that does not change which would be suitable and safe for matching against in the test. The difficulty with this approach is that it does not neatly document itself, as opposed to the previous two approaches.
I've found myself unsatisfied with Django's ability to render JSON data. If I use built in serializes then database foreign key relationships are not included in the data (only the keys). Also, it seems to be impossible to include custom data in the json feed that isn't part of the model being serialized.
As a test I implemented a template that rendered some JSON for the resultset of a particular model. I was able to include/exclude whatever parts of the model I wanted and was able to include custom data as well.
The test seemed to work well and wasn't slower than the recommended serialization methods.
Are there any pitfalls to this using this method of serialization?
While it's hard to say definitively whether this method has any pitfalls, it's the method we use in production as you control everything that is serialized, even if the underlying model is changed. We've been running a high traffic application in for almost two years using this method.
Hope this helps.
One problem might be escaping metacharacters like ". Django's template system automatically escapes dangerous characters, but it's set up to do that for HTML. You should look up exactly what the template escaping does, and compare that to what's dangerous in JSON. Otherwise, you could cause XSS problems.
You could think about constructing a data structure of dicts and lists, and then running a JSON serializer on that, rather than directly on your database model.
I don't understand why you see the choice as being either 'use Django serializers' or 'write JSON in templates'. The middle way, which to my mind is much more robust and fits your use case well, is to build up your data as Python lists/dictionaries and then simply use simplejson.dumps() to convert it to a JSON string.
We use this method to get custom JSON format consumed by datatables.net
It was the easiest method we find to accomplish this task and it looks very fine with no problems so far.
You can find details here: http://datatables.net/development/server-side/django
So far, generating JSON from templates, we've run into the need to escape newlines. Looking at doing simplejson.dumps() next.