Skip to content
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

Any future roadmap to implement staticman based commenting system #35

Open
coolbrg opened this issue Sep 5, 2016 · 2 comments
Open

Comments

@coolbrg
Copy link

coolbrg commented Sep 5, 2016

It looks like Staticman will be becoming ideal solution for static site commenting solution. Any future roadmap for this feature?

BTW, thanks for the nice blog theme.

@brikis98
Copy link
Owner

brikis98 commented Sep 5, 2016

I think @eduardoboucas's Staticman is an awesome project, and I'd love to use it, but there are a few things that make me a bit reserved before adding it:

  1. No notifications for participants in a comment thread. That means you can't really have a conversation. People will post a comment and then forget all about it and never see the replies.
  2. Are there user accounts? That is, when someone posts a comment, is there a name, image, and link to find more info about them?
  3. A variety of security concerns:
    1. Giving write access to my repo (and many other repos) to a single GitHub account. This makes the Staticman GitHub account a prime target for hacking.
    2. CSRF support. Without a basic CSRF token, it seems like anyone anywhere could post to the URL https://api.staticman.net/v1/entry/{your GitHub repository}/{your repository name}/{the name of the branch} and either automatically generate a comment on your site or at least flood you with PRs. Is there at least rate limiting?
    3. Injection attacks. Depending on how the Staticman code writes into your data directory, an attacker could craft a POST that breaks out of that code and ends up modifying other files and folders in your repo. Of course, you can prevent these sorts of attacks through escaping, but YAML, which is typically used for Jekyll data files, and the various YAML libraries out there are notorious for really nasty injection exploits.

@faithworkcamps
Copy link

All of brikis98’s concerns for Stickman are valid. Nonetheless, Disqus comes with its own set of issues. FWIW I’ve implemented Stickman on a yevgeniy-brinkman-homepage cloned site if this is still of interest to you. Huge thanks to brikis98 for his design!
faithworkcamps/faithworkcamps.github.io

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants