Open coditva opened 7 years ago
Just append /admin at the end of your URL to access the admin panel. A DB entry would be a good idea if Sharing playlists was a login-only feature. Then every registered user would have his own DB record of playlists. Is that what you had in mind?
Arey I know about the '/admin' thing. What I'm asking is, Is there a check in the code such that, say, a command is run only by an admin... Yes, it'll be basically one db for all 'user-playlists', and each user will have an array field for storing the playlist IDs...
Actually the socket is open for everyone (we need to close it to avoid breach). We have only created a check in the front-end template.
@SebastinSanty, Will do that too...
This is the check https://github.com/OSDLabs/Encore/blob/master/views/index.html#L23-L25
@SebastinSanty Hard scan is registered to one of the socket events in the backend right?
@UtkarshMe Why don't you include your middleware functions inside the socket.on
listener for all admin events?
@prampey Yes, it is
I think it pertains to socket.on('scan_update'
in the socket.js
file.
Isn't socket.js
public? Also, I am unable to figure out a way to get user session data (ie username or id) in the socket events in the routes/index.js
file... :/
@UtkarshMe Yeah, it is public and that's the downside. This can be exploited only if the enduser makes a socket-client and connects (rare case). After our initial release, we can create an authenticated socket connection, to avoid external interference
This? https://github.com/OSDLabs/Encore/blob/master/routes/index.js#L110-L132
Even though it's public, you can use the middleware functions to ensure access to only an admin or registered user right?
I got two ways to solve this issue :
sessionOpts
and access user details in the socket calls. (Ref)So based on above we can have two ways to store/get playlists:
Also we might be able to tackle the admin problems with this.
So yeah if you people agree with me on this then we can continue with either of the ideas or improve on them.
@SebastinSanty, that works for a function that takes req
as an argument (ie a middleware), but it fails for socket... I think passport.socketio
, like @mukkachaitanya suggested, should work...
Oh yes, I agree. I didn't notice the socket events you mentioned.
I think neDBSessionStore would be better in long run as we will be able to recommend songs and even implement public/share playlists better this way (I think so!).
Though I am not against passport.socketio
, as at first glance even I thought this would be best.
Addresses #5 Do not merge. Not complete. Will keep adding commits as things are done. What works:
What I want to know is,