Internal server error 500 when getting objects with match filter about cti-taxii-server

[diedel]

With --debug--mode enabled I can see more info:

Traceback (most recent call last):
  File "/home/stopit/.local/lib/python3.5/site-packages/flask/app.py", line 2463, in __call__
    return self.wsgi_app(environ, start_response)
  File "/home/stopit/.local/lib/python3.5/site-packages/flask/app.py", line 2449, in wsgi_app
    response = self.handle_exception(e)
  File "/home/stopit/.local/lib/python3.5/site-packages/flask/app.py", line 1866, in handle_exception
    reraise(exc_type, exc_value, tb)
  File "/home/stopit/.local/lib/python3.5/site-packages/flask/_compat.py", line 39, in reraise
    raise value
  File "/home/stopit/.local/lib/python3.5/site-packages/flask/app.py", line 2446, in wsgi_app
    response = self.full_dispatch_request()
  File "/home/stopit/.local/lib/python3.5/site-packages/flask/app.py", line 1951, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/home/stopit/.local/lib/python3.5/site-packages/flask/app.py", line 1820, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/home/stopit/.local/lib/python3.5/site-packages/flask/_compat.py", line 39, in reraise
    raise value
  File "/home/stopit/.local/lib/python3.5/site-packages/flask/app.py", line 1949, in full_dispatch_request
    rv = self.dispatch_request()
  File "/home/stopit/.local/lib/python3.5/site-packages/flask/app.py", line 1935, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/home/stopit/.local/lib/python3.5/site-packages/flask_httpauth.py", line 105, in decorated
    return f(*args, **kwargs)
  File "/home/stopit/.local/lib/python3.5/site-packages/medallion/views/objects.py", line 104, in get_or_add_objects
    api_root, id_, request.args, ("id", "type", "version"), start_index, end_index,
  File "/home/stopit/.local/lib/python3.5/site-packages/medallion/backends/mongodb_backend.py", line 21, in api_wrapper
    return func(*args, **kwargs)
  File "/home/stopit/.local/lib/python3.5/site-packages/medallion/backends/mongodb_backend.py", line 186, in get_objects
    {"mongodb_collection": api_root_db["manifests"], "_collection_id": id_},
  File "/home/stopit/.local/lib/python3.5/site-packages/medallion/filters/mongodb_filter.py", line 45, in process_filter
    if self.filter_contains_marking_definition(pipeline):
  File "/home/stopit/.local/lib/python3.5/site-packages/medallion/filters/mongodb_filter.py", line 192, in filter_contains_marking_definition
    if "id" in pipeline[0]["$match"].keys() and pipeline[0]["$match"]["id"].startswith("marking-definition"):
AttributeError: 'dict' object has no attribute 'startswith'

[emmanvg]

Hi @diedel, thanks for submitting this report!

Currently we are working on both versions of the TAXII Server (2.0, 2.1) and we have a couple of changes staged for an upcoming release. This issue in particular has been resolved and its present on the current master branch. Keep in mind that we are still in a 0.X.Y release and some features may not be present or bugs still need to be addressed. Definitely appreciate people trying it out.

As far as release schedule, its hard to provide an exact date but we should be close for making a new release.

[diedel]

Hi emmanvg,

I tried to install the 'master' version of medallion and, yes, the problem is solved. But I had to revert to 0.4.0 again because I noticed the timestamp fields (created, modified, ...) are saved as floats and not as strings, and this breaks our current frontend.

So to workaround the multi-id match bug, now I launch individual match queries, i.e.:

• GET /trustgroup1/collections/91a7b528-80eb-42ed-a74d-c6fbd5a26116/objects/?match%5Bid%5D=identity--733c5838-34d9-4fbf-949c-62aba761184c

• GET /trustgroup1/collections/91a7b528-80eb-42ed-a74d-c6fbd5a26116/objects/?match%5Bid%5D=threat-actor--dfaa8d77-07e2-4e28-b2c8-92e9f7b04428

Well, actually I call the datastore.query() function of the stix2-python library for each ID.

Thanks for your work!

[emmanvg]

That's correct @diedel, we found a limitation within MongoDB where any construct built using the Date Type losses valuable precision in objects or manifest records. Which is a result of the BSON Types and how they defined it. The decision was to use floating-point representation going forward.

[emmanvg]

@diedel I am closing this issue as we think the issue has been resolved. Feel free to re-open if you think that is not the case. Thanks for the feedback -- good to know you are using other tools we also support.

[ManuelZe]

hi @emmanvg
I get an internal server error when I do a get_object on a collection in this way though
print (collection.get_object ('indicator - 6770298f-0fd8-471a-ab8c-1c658a46574e'))

`
from taxii2client.v21 import Collection, as_pages

collection = Collection(url = 'http://127.0.0.1:5000/trustgroup1/collections/91a7b528-80eb-42ed-a74d-c6fbd5a26116', user='admin', password='Password0')

print("_______________")
print(collection.title)
print(collection.description)
print(collection.get_object('indicator--6770298f-0fd8-471a-ab8c-1c658a46574e'))

`

Here is my source code. And the first three prints work, except the last one.

When I take a look at the logs on server mongo I have this error

`

Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/werkzeug/serving.py", line 323, in run_wsgi
execute(self.server.app)
File "/usr/lib/python3/dist-packages/werkzeug/serving.py", line 312, in execute
application_iter = app(environ, start_response)
File "/usr/lib/python3/dist-packages/flask/app.py", line 2464, in call
return self.wsgi_app(environ, start_response)
File "/usr/lib/python3/dist-packages/flask/app.py", line 2450, in wsgi_app
response = self.handle_exception(e)
File "/usr/lib/python3/dist-packages/flask/app.py", line 1879, in handle_exception
server_error = handler(server_error)
File "/home/manuel/.local/lib/python3.9/site-packages/medallion/init.py", line 105, in handle_error
"description": str(error.args[0]),
IndexError: tuple index out of range

`

Any ideas, please?

[rpiazza]

Reopened by @ManuelZe

[ManuelZe]

Thank you for opening up the problem once again.
Do you have any idea about the error I am encountering?

[clenk]

Hi @ManuelZe, sorry for the delay. We haven't been able to reproduce the error you're encountering. Is there any other information you could give us, like library version, and how you're running it? It looks like you're running it with wsgi?

[chisholm]

We'd like to know where the original exception came from, but it would also be good just for the sake of general robustness not to assume that error.args has anything in it. That problem could be fixed now, and then if the real problem which caused the error handler to be invoked in the first place ever happens again, we should get a normal error response with a clue to what that problem is. It will be much easier to diagnose and fix it.

[clenk]

Yes, we're currently working to fix that.