Closed (fixed)
Project:
Drupal.org security advisory coverage applications
Component:
module
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
28 Dec 2013 at 20:59 UTC
Updated:
29 Jan 2014 at 17:20 UTC
Jump to comment: Most recent
Comments
Comment #1
PA robot commentedThere are some errors reported by automated review tools, did you already check them? See http://pareview.sh/pareview/httpgitdrupalorgsandboxfly2abhishek2162225git
We are currently quite busy with all the project applications and we prefer projects with a review bonus. Please help reviewing and put yourself on the high priority list, then we will take a look at your project right away :-)
Also, you should get your friends, colleagues or other community members involved to review this application. Let them go through the review checklist and post a comment that sets this issue to "needs work" (they found some problems with the project) or "reviewed & tested by the community" (they found no major flaws).
I'm a robot and this is an automated message from Project Applications Scraper.
Comment #2
abhishek-anand commentedThe issues were in a minified file, which was added to improve performance. However, removed jserror.min.js for now.
No more issues identified at http://pareview.sh/pareview/httpgitdrupalorgsandboxfly2abhishek2162225git
Comment #3
xqus commentedWhat if I create a POST request containing JS or HTML in any of the fields? You should always filter your output that comes from an untrusted source.
Comment #4
abhishek-anand commentedHi,
check_plain and filter_xss were already added in most of the fields,
Added check_plain for stack, cookie and timestamp. Other fields that do not have a check_plain is computed from User Agent string, hence check_plain is not needed.
Thanks,
Abhishek
Comment #5
abhishek-anand commentedComment #6
xqus commented* Typo in hook_help()? JSerror module watches you JavaScript
*Typo in hook_init()? // Check if jserr_en cookie is enabled. I not set to cookie.
I really can't find anything to put my finger on here. But I have only done a manual code review, no testing.
I can see flood control is disabled by default. I would think that at least at least you should have some limit.
I would set this to RTBC, but I think we should get some more eyes on this.
Comment #7
abhishek-anand commentedThanks xqus!
Removed the typos. Set the flood control values
jserror_page_limit : 100
jserror_client_limit : 10000
Comment #8
abhishek-anand commentedComment #9
klausiRemoving review bonus tag, you have not done all manual reviews, you just posted the output of an automated review tool. Make sure to read through the source code of the other projects, as requested on the review bonus page and provide feedback on that.
Comment #10
andystone78 commentedHi Abhishek Anand.
The module holds up well and i cant see much wrong with it. I have noticed a few very minor issues though:
It would be nice to have a 'configure' entry in your .info file to direct users to your settings page from the modules page, eg:
configure = admin/config/development/jserrorThere are a few typos in jserror_admin_settings():
"The percentageof visits..."
"Persentage of users..."
A long-shot admittedly, but in theory anonymous users can access the jserror_errors_overview form, which leads to entries in thier $_SESSION array, thereby disable anonymous page caching. It may be worth noting in the README that this disables page caching when used anonymously.
Good luck with your module
Andy
Comment #11
abhishek-anand commentedHi Andy,
Thanks for reviewing my module.
'configure' entry has been added in .info file.
Spelling errors have been corrected.
Have added note section in README.txt mentioning the anonymous user caching issue if 'access site report' permission is granted to anonymous users.
However, I believe there are other modules which adds entries in $_SESSION variable in callbacks with 'access site reports' permission (e.g., dblog module does the same thing for its report section). Hence, I think this issue should not make any impact.
Thanks,
Abhishek
Comment #12
anil614sagar commentedHi Abhishek,
Some findings after a manual review.
1. Use l function in jserror_list.tpl.php instead of html a tag
2. Use db_insert to insert records in jserror.module file line no 153
Database::getConnection('default', 'default')->insert('jserror')
3. Use Drupal.settings.basepath in js while referring files in jserror-init.js file line 20 similar in jserror.js
s.src = "/sites/all/modules/jserror/jserror.js";
Cheers,
Anil Sagar
Comment #13
abhishek-anand commentedHi Anil,
Thanks for reviewing my module!
1. Removed
<a>tag and added l() function2. Any specific reason to not to use
Database::getConnection()->insert? db_insert uses the same. IMHO its legit to userDatabase::getConnection()->insert3. Drupal.settings.basepath cannot be used in jserror-init.js as the code has to start executing even before Drupal.settings is loaded.
Thanks,
Abhishek
Comment #14
anil614sagar commentedComment #15
abhishek-anand commentedComment #16
abhishek-anand commentedActually Drupal.settings.basePath works coz the snippet binds to load event.
Added the same.
Thanks,
Abhishek
Comment #17
fusionx1 commentedAfter installing the jserror and visited some of the pages ive checked the javascript logs and found nothing. I visited again some of the pages with jquery interactivity and when i return back to check javascript logs in Report UI i found this, a screenshot of the mysql error - http://screencast.com/t/dZvdLS1Fj .
It was resolved when i cleared my cache and now its back to normal.
Comment #18
abhishek-anand commentedHi Paul,
Thanks for reporting the issue.
There was a malformed query in jserror_cron which has been corrected now.
For the module to show entries in admin/reports/jserror, there should be some JS errors introduced on any page.
Thanks,
Abhishek
Comment #19
abhishek-anand commentedComment #20
@purushHi Anand,
http://pareview.sh/pareview/httpgitdrupalorgsandboxfly2abhishek2162225git automation review tool shows a small issue.
I have installed the module and you have followed the Drupal API and FAPI standards.
Other than that I found little notes on code standards,
1 - There is no need of explicit notation for default submit handler of the form like
This is something you have maintained in the other form "jserror_filter_form".
All looks good to me apart from the above. Your module looks great and Good luck man
Comment #21
abhishek-anand commentedHi Purushothaman,
Thanks for the review. Both the problems are solved now.
Comment #22
klausimanual review:
But otherwise looks RTBC to me. Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.
Assigning to mlncn as he might have time to take a final look at this.
Comment #23
@purushUpon Manual review:
1. Sorry i didn't noticed it. I Agree with the issue.
2.
In this module case, It should load on all the pages even if there is no html delivered.
3. Basically 'jserror_save_errors' is an page callback which doesn't have error details as parameters and its always work with browscap module. so no issues on bogus/faked JS error submit
4. Use drupal_write_record/db_insert instead of
5. Haven't used t() on title and description of the menus (Translates a string to the current language or to a given language.)
6. Need to check the is_numeric of the data on
7. Helper functions name should starts with underscore
Comment #24
@purushComment #25
klausiIf you don't deliver HTML then javascript will not be executed, so really hook_page_build() should be used.
Of course anyone can submit POST values to jserror_save_errors() and the module will just write them to the database. So an attacker could send bogus/fake error messages, which could be confusing. But as I said there does not seem to be a way to prevent that, so I would not consider it a security issue.
Do not use t() in hook_menu(), so the current code is fine.
The rest don't seem to be critical application blockers, so back to RTBC.
Comment #26
abhishek-anand commentedHi Klausi,
Thanks for your review! I had a great learning through your review.
Changed hook_init to hook_page_build().
Thanks,
Abhishek
Comment #27
klausino other objections for more than a week, so ...
Thanks for your contribution, Abhishek Anand!
I updated your account so you can promote this to a full project and also create new projects as either a sandbox or a "full" project.
Here are some recommended readings to help with excellent maintainership:
You can find lots more contributors chatting on IRC in #drupal-contribute. So, come hang out and stay involved!
Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider reviewing other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.
Thanks to the dedicated reviewer(s) as well.
Comment #28
abhishek-anand commentedThanks Klausi and all reviewers!