mirror of
https://github.com/nishchayp/DAMN.git
synced 2026-04-24 22:55:59 +03:00
[GH-ISSUE #10] Improvement: make and accept access request for multiple IPs at once. #7
Labels
No labels
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/DAMN#7
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @nishchayp on GitHub (Dec 3, 2017).
Original GitHub issue: https://github.com/nishchayp/DAMN/issues/10
Presently multiple requests are to made for multiple IPs and if one request exists another request from the same person for another IP can't be made until admins have responded to previous request.
@ekamwalia commented on GitHub (Dec 10, 2017):
I think the best way to resolve this is to let the user make an access request only for some specifics IPs/Projects.
To do this, with the GET request to the options routes, we will send a JSON of all the current IPs that the user can request access for. The AccessRequested table will hold the IP for which a user requested access and in our query we will check if the user has made a request for that particular IP, instead of just checking the email.
@therealssj @Diuda Can we let the users see all the droplets we have?
@nishchayp commented on GitHub (Dec 10, 2017):
A few things, the "/options" route is a Google OAuth2 api callback which returns a token which is then sent to a Google endpoint for authentication which then hits back with a 200 if the token is legit, so basically that is a route for interaction with OAuth2 api so IMO i don't intend to make it interact with our DB as in it would be kind of messy and awkward.
The present implementation of the "/makeAccessRequest" route is that the user does not need to know the IPs they just send their ssh key with a message about what they are working on and the admin sends a POST request with the IP they will get access to in "/grantAccessPrivilege" route.
So basically in POST request except for string take array of string and run a for loop to send multiple requests, with it there are a bit of intricacies but they can be handled.
So go ahead if you want to implement.
@ekamwalia commented on GitHub (Dec 10, 2017):
The array of strings seems like a very messy approach.
An alternative to the problem with the options route is that we can add a new page or a modal box for the form for requestAccess. And when this page is rendered or the modal box is opened, we can query the latest project/droplet details form the backend and display that
@nishchayp commented on GitHub (Dec 11, 2017):
That is front-end you are talking about.
There is no problem problem with the "/options" route. Also "/requestAccess" doesn't require change IMO.
The thing is we have to modify the route in the api while not breaking the shell script. I'll probably fix this issue in a day or two.
@ekamwalia commented on GitHub (Dec 12, 2017):
Modifying the /makeAccessRequest wont in any way break the script, because that route doesn't interact with the scripts at all.
What alternative solution are you thinking of?
@nishchayp commented on GitHub (Dec 12, 2017):
Yes exactly, the route that needs modification is "/makeAccessRequest". Probably array of strings for now. If it works fine then well and good or else maybe change it up at a later stage. This issue anyways is kind of trivial right now.
@ekamwalia commented on GitHub (Dec 12, 2017):
IMO, the user should not have to send a message, and should instead get to select the exact project they want access to. This will also make it easier for the admin because then for every request admins just need to click a "grant access" or "reject request" button instead of reading through the message, deciding the droplet they need to give access to, then type in that particular IP and grant access
I think we should hold of on this for now and decide when we have a base frontend ready and a better understanding of the flow of the app. Anyway as you said, this is a trivial issue, one that can wait for a few days