softwareengineeringdaily / software-engineering-daily-api Goto Github PK

Okay - I got a bit confused over this one and responded posted too quickly (web vs mobile facebook auth). But this morphs my issue into a new one - If we're going to use facebook mobile token auth should we not be implementing web based as well? I'm willing to give it a try.

I'm trying to get the API documented up-to-speed with swagger/jsdoc and am struggling with Facebook auth. It doesn't follow the typical passport/oauth2 flow (two GET routes - one for request access, one with callback). I also don't see this in use in any of the front-ends. Can anyone provide clarity?

Algolia (maybe free because we are Open Source)
ElasticSearch

The vote logic is currently in the post controller. We need to organize it into the vote controller and remove the old unused code.

Hey everyone,

This probably was discussed on the Slack channel and I just missed it but would love to have the option to pick a different speed for the audio.

Currently will only be validated on updates but we eventually want to require these fields: [username, email, name]

What do you guys think? If we are using "real names" to display in the app we should require that field, otherwise we can use username (at the moment probably contains emails so that's why I'm adding name).

I can see leaving email as optional. Seems a bit weird to have both email and username but it's not the end of the world? Eventually we can allow users to login via either username or email like many sites do.

See: https://github.com/SoftwareEngineeringDaily/software-engineering-daily-api/pull/46/files#diff-8ea35768102b97164f16aeef4752f028

Per this PR:

https://github.com/SoftwareEngineeringDaily/software-engineering-daily-api/pull/28/files

In order to fully implement #3 (adding social auth), there needs to be a Facebook app created and configured at https://developers.facebook.com

TravisCI is linked correctly but the config seems to be incorrect.

What's the intended use of favoriting vs upvote/downvote?

I see the use of upvote/downvote as similar to youtube which makes sense. Why also have favoriting? From my perspective, you would have one function or the other in an app, but not both.

Similar but perhaps semantically more meaningful might be "bookmark", which could be used if you want to keep as a list eps to listen to later, eps you might like to listen to again/do more research on related resources. Upvote/downvote would be intended only for those you've listened to (or partially listened to) already.

It is becoming a consensus that Javascript needs to be statically typed to prevent bugs. I'd like to add Flow to this: https://flow.org/. I'm also open to looking in to ReasonJS/ReactReason, but I think that may be front end only.

A user called ambrosi9 pinged me on Slack and said they cannot login and aren't sure what to do.

We need to set up password reset via email.

Is there an ad hoc solution that we can implement to get ambrosi9 back online?

Seems that if the token is invalid user stays logged in.

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because we are using your CI build statuses to figure out when to notify you about breaking changes.

Since we did not receive a CI status on the greenkeeper/initial branch, we assume that you still need to configure it.

If you have already set up a CI for this repository, you might need to check your configuration. Make sure it will run on all new branches. If you don’t want it to run on every branch, you can whitelist branches starting with greenkeeper/.

We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

Once you have installed CI on this repository, you’ll need to re-trigger Greenkeeper’s initial Pull Request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper integration’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

There are two mongodb services declared in the docker-compose.yml file: a mongo 3.5 and a mongo 3.4.2. This makes it confusing as to which container hostname to use in the .env.docker_example.

This wasn't a problem previously, because /users wasn't used in index.route.js. But now that it is, a call to api/users/:userId will return all user info even if you're not that same user or even logged in.

Something that might address this as well as support issues #36 and #56 going forward, could be a toAuthJSON and toProfileJSON functions which would only expose those elements to the same authenticated user and to anyone respectively. Here is a similar example.

Because there is both auth and user controller it seems it would be easiest to put in model but its worth discussing.

As a stop gap - simply disabling the route might be the best choice (my guess is it isn't used anywhere, because the /users was only recently exposed)

Currently the implementation is not ideal.

Here is an example on one idea on how to make it a bit cleaner:

#72

// TODO: add a test to make sure we can't update
// username to that of an existing user!

// TODO: add test so we make sure we can only modify our
// own data. (I've been testing this edge case with postman).

S3 probably

(node:23702) DeprecationWarning: open() is deprecated in mongoose >= 4.11.0, use openUri() instead, or set the useMongoClient option if using connect() or createConnection(). See http://mongoosejs.com/docs/connections.html#use-mongo-client

Facebook auth is incorporated in PR #15. Opening this issue to make sure the Google auth is implemented so we can close #3. See #3 for related information.

Was sent this, will need to double check what's going on but might just need to have instructions on how to reload npm install inside the container

software-enginnering-daily-api -> sedaily-backend

limit is a parameter in the posts.controller list method but doesn't actually do anything. post.model expects limitOption instead and so the default value of 10 is always used regardless of what is provided.

I think this would be a fairly straight forward fix - but if I wanted to update the tests it gets a little more complicated (see below). So should this be done now, or, since existing front-end app functionality doesn't seem to be affected, perhaps it's better addressed along with implementation of type system - see issue #9

For the tests - I'm looking at post.test.js and it seems like the idea is we're mocking the creation of data in an empty Mongo test database. However, when saving a new posts, there is no date because there is no date in the Mongoose model. As far as I can tell this is only available when loading data from wordpress - so I can't see how the should get all posts (with limit and skip) test would pass with mock data (not loaded from WP).

Anyways, I could figure this out but I'm wondering if it's worth it to be done now or just addressed along with the type system because the whole code base will be changed anyways.

Heroku is set up with two pipelines:
Backend: https://dashboard.heroku.com/pipelines/fede41a2-4266-4945-ad9b-6dbbc048390a
Frontend: https://dashboard.heroku.com/pipelines/05ed1ae0-571e-459b-bca2-9a3aa3562bc9

Both of these have staging environments (4 total environments)

master is deployed to all 4

Backend environments respond to Postman requests, but not frontend requests

Update User model so it doesn't include passwords on find queries..

Use: password: { type: String, select: false }
And including the password should be explicit, via : query.select('+password')

Right now we loop through parent comments and make a query for each of them to get their children. What we really should be doing is making 1 query that grabs all the ids of the parents and then we make a second query to fetch all the children. So two queries instead of number-of-parent-comment-queries.

Just in case we break anything

We should make a global event log to decouple event creation from writing to the database. That will make it easier for people to build applications on top of SE Daily infrastructure.

We need to add social auth. I'm also open to other auths as well, but Facebook and Google were requested. The requirements are:

1. 1 url, for social auth taking in the name as a param
2. A library to handle controller logic
3. The route must return the JWT. We already use JWT in the normal auth

Steps to reproduce

• run npm run test:coverage
• Only tested on macOS Sierra

Expected

• Coverage report is printed to terminal as shown below and coverage directory is populated with appropriate metrics

=============================== Coverage summary ===============================
Statements   : 68.03% ( 349/513 )
Branches     : 51.52% ( 102/198 )
Functions    : 52.21% ( 59/113 )
Lines        : 68.8% ( 333/484 )
================================================================================

Observed

• Terminal prints "No coverage information was collected, exit without writing coverage information"

Possible Fix

• Without too much testing, updating from [email protected] to [email protected] generates the coverage report. Not sure if there are other ways to fix this with a different configuration.

Specifically for usernames.

Currently done at the controller level / auth route:

https://github.com/blakehaswell/mongoose-unique-validator

Not sure if there should be pending tests.

Users need to be able to favorite posts. We need:

1. Route to favorite/unfavorite
2. A route to return the user's favorite

Just a note here, that we should set up guidelines for the best practices and architecture we want to follow. We don't have to implemented everything at once, but it would be good to have a plan and outline.

Update I have a doc written and will post that soon. Then we can develop tasks based on that. Feel free to post your ideas.

Open to discussion. Here are some ideas.

1. Help Wanted
2. Investigating
3. In Progress
4. Ready for Review

Also should tie into Heroku.

We need a separate model to track user listening. This will help create recommendations for our ML algorithms, but will also help us not recommend podcast the user already listened to. Extra points if you have a good solution (probably using Redis) to quickly get what the user listened to.

Even if encrypted & even if returning my own password hash.

It seems it still does return hashed passwords in certain cases.

This method did not work:

#48

Reproduce on frontend by looking at Vuex in chrome and seeing "me.password" field