New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cve search 399 #508
Cve search 399 #508
Conversation
…od instead of a fixed connection to mongodb
Whoaaa, you are fast. That's great. The vendor browsing works as expected. https://cvepremium.circl.lu/browse We are still doing some tests with the API especially the legacy. We will also update the CPE module to use the new API interface. |
Awesome! |
I see the CPE module you mentioned is the one from MISP; great! Once this change makes it to master the first thing I would like to do is to update the (gh-pages) documentation. I would like to move to sphinx to facilitate automatic documentation building on master commits; any objections? |
Good idea! |
Another small issue, the search on top right seems to be broken. |
I see what you mean! On it! |
Done! |
Thanks! Another question regarding sanity check on the query fields before passing it to MongoDB. Would it be safer to have a set of rules to do some sanity check before passing it to MongoDB.
|
Yes; definitely; good catch! I'll start working on it! |
Done! Some sanity checks where already in place; added the specific integer checking to the existing checks in JSONApiRequest |
Cool! Found something weird in the current branch with the updater which stops at random interval:
I find it strange that the HTTP response is missing the |
That is indeed weird..... Hard to troubleshoot as well; there’s not much control over the headers being send back to us.... We could add some exception handling and if the header is missing the last-modified field use the current update timestamp instead? |
On second thought; using the current timestamp might conflict at some point with the last-modified header field if it is present on the next update cycle... So using a value to explicitly state it was not received is probably better, don’t you think? |
@adulau Did you encounter any other issues during your tests? If not I might be able to add some exception handling on the updaters' response headers this weekend; once that is done do you consider the PR a beta version? If so we might consider dropping a message on Gitter for the community to take a sneak peak at this version and do some testing/evaluation as well? |
Thanks a lot. Sure the updater's exception handler is a good idea (also for intermittent issue like SSL/TLS handshake. The only remaining part is the CAPEC entries but the rest is fine and we could consider this as beta. |
Yes the capec issue; did you get your head around that one because I cannot reproduce it on my end.... |
… of the last_modified header and one for general download failure which will solve issue 513.
I think we can merge and fix the minor part later before doing an official release. Ok for a merge? |
Yes; definitely Ok! The minor part you are referring to is that still the CAPEC? |
Yep but it's not critical. |
Thanks a lot for PR, it's a great improvement. |
@adulau As promised the first version of the API re-write; could you test this in the beta instance?
Work done:
Install instructions:
WebInterface
to something other then 'Full' should mimic this behaviour;Love to hear your comments / further thoughts!
fix #399