venantius / darg Goto Github PK

https://github.com/weavejester/environ

This is a security and design issue. I'm not too bothered about it right now but at some point it'll be a smart idea. Stuff that this impacts:

• Stripe
• Mailgun
• Github

Some of these (Mailgun, for instance) have Heroku add-ons available where they'll put stuff into your environment for you!

Issue needs to be resolved less we trigger a resonance cascade scenario and find ourselves trapped in Xen.

See error below: Lobos migration should set foreign-key constraints to ON DELETE CASCADE for team_users table, since deleting a user/team should also delete the relationship with their teams/users.

We may want to think about how we handle tasks from different users: deleting a user currently would maintain their unique id linked to the task, but Darg would be unable to find the user's name or email address.

org.postgresql.util.PSQLException: ERROR: update or delete on table "users" violates foreign key constraint "team_users_fkey_users_id" on table "team_users"
Detail: Key (id)=(3) is still referenced from table "team_users".

Either verify that Korma does this or modify model functions to ensure database security

• Insert
• Update
• Delete
• Select

What the default looks like:

Taking away the outer border:

Taking away the outer border and setting the inner text to "clouds" / ECF0F1

Behavior for this form is controlled by

.navbar-inverse .navbar-form .form-control:focus {
  border-color: #1abc9c;
  color: #1abc9c;
}

in flat-ui.min.css

Right now there's a ring server set up to provide the barest hello world minimum. This should be expanded, presumably with some decent design.

Right now the DNS records point to my jackalope1-1 linode, and Mailgun is configured off of that. I suspect that Linode is not going to be the ideal deployment route (especially when compared to something like Heroku or aws), but it can suffice for now.

https://devcenter.heroku.com/articles/debugging-clojure

.login-form:before {
content: '';
border-style: solid;
border-width: 12px 12px 12px 0;
border-color: transparent #edeff1 transparent transparent;
height: 0;
position: absolute;
left: -12px;
top: 35px;
width: 0;
-webkit-transform: rotate(360deg);
}

On line 4400 of flat-ui.min.css

MVP

• GitHub (3.4M users, according to Wikipedia)

V1

• Trello (4M users source)
• JIRA + Confluence.
• Asana (my guess is about 1M users, based on this and this)
• Basecamp (Hypothesis of 5M users "by" 2012 source -- we should probably just assume 5M users now.). API Repo

V2

• Phab

https://circleci.com/gh/ursacorp/darg/37

REPL testing confirms model works, but the tests in v1_tests seem ineffective.

We'll obviously need a Stripe integration if we want to get paid.

• OAuth flow (https://developer.github.com/guides/basics-of-authentication/)
• Commit webhooks
• PR webhooks
• Issue webhooks

This could be refactored to actually not look like shit.

I think this might be a cool feature.

Resources
http://webdesign.tutsplus.com/articles/build-an-html-email-template-from-scratch--webdesign-12770
https://www.campaignmonitor.com/email-templates/all/

Graphics
https://octicons.github.com/ (the GitHub icon set)

The settings page. Assuming this is gonna live at /settings

User settings

• Personal e-mail time of day
• Digest time of day

Team settings

• Add / remove team members
• Payment settings.

See: http://documentation.mailgun.com/user_manual.html#routes for how e-mail via mailgun can either be forwarded, or stored with a callback.

• Create an endpoint at /api/v1/email
• Write tests (200 response code with mocked get requests, etc.)
• Write code to parse "accomplishments" / "dargs" from general e-mails
• Write code to parse "dargs" but exclude reply context
• Write parsed accomplishments/dargs into the database.
• Verify the token hash that gets forwarded from Mailgun. (#17)

Stormpath docs here: http://docs.stormpath.com/rest/product-guide/#.VAty3WRdU00

• Authenticate a user
• Delete a user
• Update a user
• Add a user
• Allow a user to re-set their password

This is a subtask of #5 - we should use the darg.core namespace to set up some Compojure routes.

https://github.com/weavejester/compojure

Current Status:

We can parse an email map returned from Mailgun, retrieve the relevant task list and metadata, and insert the list into the database

To-Do's:

• improve task-list parser to handle context, block quotes, ordered and unordered lists (NOT DOING)
• verify emails to ensure user is authorized to post tasks.
• create auto-reply for failure scenarios
• Verify Mailgun token for authentication
• improve date parser to handle different date formats and placements in subject line (NOT DOING)

I had to implement a custom Phabricator linter yesterday, and in reading through the Phab docs I came across this:

Code review is most valuable when it's about the big ideas in a change. It is substantially less valuable when it devolves into nitpicking over style, formatting, and naming conventions.

The best response to receiving a review request full of style problems is probably to reject it immediately, point the author at your coding convention documentation, and ask them to fix it before sending it for review. But even this is a pretty negative experience for both parties, and less experienced reviewers sometimes go through the whole review and point out every problem individually.

Lint can greatly reduce the negativity of this whole experience (and the amount of time wasted arguing about these things) by enforcing style and formatting rules automatically. Arcanist supports linters that not only raise warnings about these problems, but provide patches and fix the problems for the author -- before the code goes to review.

Good linter integration means that code is pretty much mechanically correct by the time any reviewer sees it, provides clear rules about style which are especially helpful to new authors, and has the overall effect of pushing discussion away from stylistic nitpicks and toward useful examination of large ideas.

It can also provide a straightforward solution to arguments about style, if you adopt a policy like this:

If a rule is important enough that it should be enforced, the proponent must add it to lint so it is automatically detected or fixed in the future and no one has to argue about it ever again.
If it's not important enough for them to do the legwork to add it to lint, they have to stop complaining about it.
This may or may not be an appropriate methodology to adopt at your organization, but it generally puts the incentives in the right places.

While we're not going to start using Arcanist, I think we should get a Clojure linter - Eastwood - set up as part of our CI process, so that it just becomes a natural part of the development flow.

I don't think we want this to be a manual step, but I could be convinced otherwise.

I can get angular expressions to evaluate but seem to be having trouble pulling Angular in. Investigate.

Search functionality exposed through the api to allow users to fuzzy search for a user or team (e.g., "Ebay", "David J", "Cellular mitosis".

Creating issue here to use as notepad for model refactoring

I believe Flat UI has its own bootstrap folder - no need to have separate bootstrap folders.

Proposal: create darg.config and darg.logging, which set the logging levels for the application. Right now logging levels are basically being set willy-nilly by various libraries, which is BUNK! It's super annoying and we need a central place where logging levels are set.

There's a bunch of stuff that needs to happen in order for us to have a solid sign-up flow:

• Team configuration page
• E-mail welcome message
• "Invite" message to follow team members (assuming the team lead can just sign other people up)
• Probably a "personal" message from me after a few days

The e-mail stuff above should probably be handled through Intercom rather than through Mailgun.

Authentication roadmap

• User inputs email and password to form
• Form hits Darg API endpoint for login: /api/v1/login
• Darg backend sets encrypted session cookie, and also sets a cleartext login cookie.
• Angular uses cleartext login cookie as cue for UI rendering
• Visible logout button appears
• Maybe write the /api/v1/logout/ endpoint first on the backend.
• Angular retrieves resources from backend in AJAX calls, all of which explicitly require the encrypted info in the session cookie (NOTE - MAKE SURE TO HAVE AUTHENTICATION REQUIREMENTS FOR ALL SIGNIFICANT RESOURCE ENDPOINTS)
• ...
• Profit!

Backend auth resources

• http://www.luminusweb.net/docs/sessions_cookies.md
• https://github.com/mmcgrana/ring/wiki/Cookies
• https://github.com/mmcgrana/ring/wiki/Sessions
• http://vijaykiran.com/2012/02/web-application-development-with-clojure-part-5/

This StackOverflow question is the best thing I've read on authentication so far. It says that as far as your Angular app goes, you can keep track of whether a user is "logged in" but ultimately it's only for UI purposes - it means nothing as far as actual auth goes. All resources are still AJAX calls to the backend, and pass session cookies along; there's no resource that can actually be retrieved without validating the session cookie.

Authentication resources for Angular

• https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
• https://docs.google.com/presentation/d/1dceqxHVLP251cOQvBh3gOrAO_G2c6W9lQ6J2JCaO1d0/edit#slide=id.g125b2853e_04
  https://medium.com/opinionated-angularjs/techniques-for-authentication-in-angularjs-applications-7bbf0346acec
  http://www.frederiknakstad.com/2013/01/21/authentication-in-single-page-applications-with-angular-js/

See: https://github.com/ursacorp/darg/pull/60/files#r17216662

Open question - not sure what the right answer is. Stormpath supports an e-mail verification workflow but that's an extra step in the sign-up process obviously.

This is a wishlist item, but Mailgun supports a lot of filtering on events:

http://documentation.mailgun.com/api-events.html#filter-field

I lowered these on purpose because it annoyed me to have to create an elaborate PW for testing purposes, and also because right now I don't want to have to deal with passing along Stormpath's fussy requirements to the end user, but it's totally something we should support.

https://api.stormpath.com/v#!directories/edit/cloud/425932 (can be set here)

Right now I'd like for us to go with the following color scheme

http://paletton.com/#uid=12T050kn-sHcnNjiHzsrAmGwRep

We can change it in the future if we want to but these are the colors I'd like to be authoritative for now.

Probably not the hugest problem, but we don't want to leave ourselves open to denial of service attacks.

As the model starts to come together, we should probably start thinking about the secret blend of herbs and spices we want to follow. This will help us figure out how to structure the backend to best support the front end.

May also help to whiteboard the chicken for bawk bawk bkawk bawk bawk

Strawman Proposal:

darg.io/team
darg.io/team/user
darg.io/team/user/tasks
darg.io/team/user/tasks?taskID={{taskID}}
darg.io/team/user/tasks?date=DDMMYYYY
darg.io/team/user/tasks?minDate=DDMMYYY&maxDate=DDMMYYYY
darg.io/team/tasks
darg.io/team/tasks?date=DDMMYYYY
darg.io/team/tasks?minDate=DDMMYYY&maxDate=DDMMYYYY
darg.io/team/admin
darg.io/team/

darg.io/user
darg.io/user/tasks
darg.io/user/tasks?date=DDMMYYYY
darg.io/user/tasks?minDate=DDMMYYY&maxDate=DDMMYYYY

We should have a really clear idea of what our user data looks like and what parts of that look like when mapped to Stormpath.

Output: a pair of convenience functions in darg.services.stormpath would be ideal:

stormpath-user->darg-user
darg-user->stormpath-user

This is what the Stormpath user ("account") data model looks like, FYI: http://docs.stormpath.com/rest/product-guide/#account-resource

If I'm doing lein test I don't really need to have access to server-style logs. Maybe. I haven't made up my mind on this one.

This issue has a dependency: #6

We don't need all the sub-libraries of clj-stripe. Clean those up once the main library has been put together.

https://github.com/ptaoussanis/timbre looks nicer than clojure.logging.

Right now we have a "placeholder" dropdown menu in the top right, but this should be replaced by a user's gravatar image.

Details on the Gravatar API can be found here, but the short version is that the gravatar API looks up images based on an MD5 of the user's e-mail (lowercased and stripped of whitespace). We could do this either in pure JS (in which case we'd either have to keep the e-mail or the MD5 of it in the cookie) or server-side (and keep nothing in the cookie and just retrieve the image based on what's in the encrypted session cookie); my inclination is that if we really consider someone's e-mail to be sensitive data then we should do it server-side (since MD5 is not cryptographically secure), and if we don't mind keeping an MD5 of their e-mail in the cookie then we should do it in pure Angular.

This should not have been added.

This is a roadmap/task-tracking issue

• [meta] Familiarize self with Angular.js (https://docs.angularjs.org/guide/module)
• [meta] Familiarize self with bootstrap
• Learn how to make API calls to the darg API
• Learn how to set cookies
• Figure out how to handle login, authentication, etc.

clj-bonecp-url.core - I think this library is altering how logging is handled and I think that's BS. We should pull it out and replace it with the URI parser used elsewhere and just deal with connection strings like that.

Need models and relationships for different parts of darg.io. The major entities that come to mind are:

• Team - a group of users working on a project, that will receive a regular darg email. Each group receives one email
• Users - member of one or more groups who can post and read events
• Event - a single update or line item from a user, which are gathered into distributions
• Digest - a collection of events for a particular group, available for viewing on Darg.io and sent via the regular email