Gitlab Lobby issueshttps://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues2020-06-16T21:47:44Zhttps://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/2Test test2020-06-16T21:47:44ZAlexander Færøyahf@torproject.orgTest testSummary
Test testSummary
Test testAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/3Create an official repository for lobby once we're reasonably confident we're...2020-07-28T15:59:31ZNick MathewsonCreate an official repository for lobby once we're reasonably confident we're going to use itLet's have things like lobby in tpo/ somewhere, once we're happy doing so. :)Let's have things like lobby in tpo/ somewhere, once we're happy doing so. :)https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/4README doesn't mention SECRET_KEY2020-07-28T13:34:03ZNick MathewsonREADME doesn't mention SECRET_KEYWhen I try to follow the instructions in the readme, I get told:
```
django.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must not be empty.
```When I try to follow the instructions in the readme, I get told:
```
django.core.exceptions.ImproperlyConfigured: The SECRET_KEY setting must not be empty.
```https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/6README doesn't say how to connect to service2020-07-28T13:34:03ZNick MathewsonREADME doesn't say how to connect to serviceI'm trying to connect to the URL it gave me, and it's saying:
```
Invalid HTTP_HOST header: '127.0.0.1:8000'. You may need to add '127.0.0.1' to ALLOWED_HOSTS.
```
Maybe together with #4, this means that we should add an "edit your sett...I'm trying to connect to the URL it gave me, and it's saying:
```
Invalid HTTP_HOST header: '127.0.0.1:8000'. You may need to add '127.0.0.1' to ALLOWED_HOSTS.
```
Maybe together with #4, this means that we should add an "edit your settings.py" step to the instructions?https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/10Automatically accept accounts from some mail providers2020-07-28T15:59:12ZAlexander Færøyahf@torproject.orgAutomatically accept accounts from some mail providersWe should consider automatically accepting new account requests from some mail providers. Right now it seems like we do get spam account request from gmail.com and googlemail.com, but all of the Riseup ones have been legitimate it seems....We should consider automatically accepting new account requests from some mail providers. Right now it seems like we do get spam account request from gmail.com and googlemail.com, but all of the Riseup ones have been legitimate it seems.
Which providers should we accept by default:
- Riseup.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/11Quiet down the new location mail from gitlab2020-08-24T22:24:18ZGhost UserQuiet down the new location mail from gitlabHey, I'm a new user and preferably login through tor, so on each successful attempt to do so, I'm greated with a mail.
A sign-in to your account has been made from the following IP address: XX.XX.XXX.XX
If you recently signed in and rec...Hey, I'm a new user and preferably login through tor, so on each successful attempt to do so, I'm greated with a mail.
A sign-in to your account has been made from the following IP address: XX.XX.XXX.XX
If you recently signed in and recognize the IP address, you may disregard this email.
If you did not recently sign in, you should immediately change your password: ..........
Is this more of a gitlab thing? Can I turn this off? For tor-project I think a mail shouldn't be sent just because of a new login location(or ip addr).https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/1Make it easy for people to create accounts AND contribute first comment/ticket2023-08-10T19:10:13ZAlexander Færøyahf@torproject.orgMake it easy for people to create accounts AND contribute first comment/ticket@nickm had an interesting point for a Gitlab Lobby to avoid the round-trip for new users who wants to submit a ticket/comment:
Users should have a way to request an account + submit their first issue or comment in one go, instead of hav...@nickm had an interesting point for a Gitlab Lobby to avoid the round-trip for new users who wants to submit a ticket/comment:
Users should have a way to request an account + submit their first issue or comment in one go, instead of having to first create an account, then wait to get access to the account, then submit their issue. This could lead some people who otherwise would prefer the anonymous account (for ease) to create an account.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/5secrets should not be in public version control2022-05-30T19:11:49ZNick Mathewsonsecrets should not be in public version controlInstead of having the secrets put in a settings.py file, they should be in some other file that settings.py references. This other file should not be under version control in our public repository.Instead of having the secrets put in a settings.py file, they should be in some other file that settings.py references. This other file should not be under version control in our public repository.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/12In the lobby approval process, show me timestamps too2023-08-10T19:10:13ZRoger DingledineIn the lobby approval process, show me timestamps tooOne easy piece of information about new signup requests, that could help with making the decision to approve or reject, would be a timestamp.
For example, if a pile of different-looking requests all showed up in the same second, this is...One easy piece of information about new signup requests, that could help with making the decision to approve or reject, would be a timestamp.
For example, if a pile of different-looking requests all showed up in the same second, this is important information for making a smart decision.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/16Automatically reject emails from known bad domains2024-03-11T12:25:04ZAlexander Færøyahf@torproject.orgAutomatically reject emails from known bad domainsWe should have a list of known *bad* domains, and automatically reject those.
The following list would be a good start: https://gist.github.com/michenriksen/8710649
This should just be a settings entry and doesn't have to be dynamicall...We should have a list of known *bad* domains, and automatically reject those.
The following list would be a good start: https://gist.github.com/michenriksen/8710649
This should just be a settings entry and doesn't have to be dynamically changable.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/30Maybe integrate anon_ticket into this application2024-03-11T12:22:13ZjugaMaybe integrate anon_ticket into this applicationAs commented at [Anonticket and gitlab lobby: plans and possibilities](https://gitlab.torproject.org/tpo/team/-/wikis/costa-rica-anonticket-discussion) it'd be great to integrate both applications as they are both programmed with Django....As commented at [Anonticket and gitlab lobby: plans and possibilities](https://gitlab.torproject.org/tpo/team/-/wikis/costa-rica-anonticket-discussion) it'd be great to integrate both applications as they are both programmed with Django.
Nice to have if it doesn't require much time.
Roadmapping for Q3.jugajugahttps://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/7README should explain how to set up and use an admin account.2020-10-12T15:57:08ZNick MathewsonREADME should explain how to set up and use an admin account.I've gotten as far with my attempted hacking as to attempt to make an account, then approve or reject the request. But I think I need to set a django password some how, and the readme doesn't explain how to do that.I've gotten as far with my attempted hacking as to attempt to make an account, then approve or reject the request. But I think I need to set a django password some how, and the readme doesn't explain how to do that.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/8Add a gitlab bot to handle basic things we want guests to do2023-08-10T19:10:13ZNick MathewsonAdd a gitlab bot to handle basic things we want guests to doWe'd like to have a gitlab bot to handle permissions we would like to grant to Guest users.
The big one is to assign a MR to a reviewer. They should also be able to assign unassigned issues to themselves, and unassign issues from them...We'd like to have a gitlab bot to handle permissions we would like to grant to Guest users.
The big one is to assign a MR to a reviewer. They should also be able to assign unassigned issues to themselves, and unassign issues from themselves.
Setting a limited set of labels could be a secondary feature.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/9Expire new-account offers after 7 days2023-06-28T18:43:08ZNick MathewsonExpire new-account offers after 7 daysWhen we create a new user via the lobby API, we send them an email that they can use to set their password.
If they don't use this email within a week, we should expire it, and not leave the user around forever.When we create a new user via the lobby API, we send them an email that they can use to set their password.
If they don't use this email within a week, we should expire it, and not leave the user around forever.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/13Notify admins of new pending lobby requests2020-10-14T16:33:20ZRoger DingledineNotify admins of new pending lobby requestsRight now I need to notice the gitlabaccountrequest tab in my browser and remember to reload it to see if new requests have arrived. Eventually my browser is going to crash and I'll lose the url and nothing will ever remind me to look at...Right now I need to notice the gitlabaccountrequest tab in my browser and remember to reload it to see if new requests have arrived. Eventually my browser is going to crash and I'll lose the url and nothing will ever remind me to look at it again.
Some sort of external notification, like an email or a line on irc or something, would be smart for the medium term -- that is, if we plan to keep the lobby in some form, and the lobby will involve humans examining requests and moving them forward, then we need a smoother way to learn that there are new requests that need attention.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/14Lobby needs to limit new gitlab name to something like A-Z, a-z, and 0-92023-06-28T18:43:07ZRoger DingledineLobby needs to limit new gitlab name to something like A-Z, a-z, and 0-9When people attempt usernames with surprising characters in them, gitlab-lobby fails to make the gitlab account. If this is a gitlab-lobby bug, we should fix it and be happy. If this is a gitlab limitation (e.g. "you can't have chinese a...When people attempt usernames with surprising characters in them, gitlab-lobby fails to make the gitlab account. If this is a gitlab-lobby bug, we should fix it and be happy. If this is a gitlab limitation (e.g. "you can't have chinese account names"), we should hack around it in gitlab-lobby by enforcing some rules on names. Otherwise we have people attempting to make accounts which we know will fail.
Thanks!https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/26Fix page layout bug2021-05-03T13:42:11ZmfonismFix page layout bugI stumbled upon this bug while working on !15.
Currently the body element is a 100% high flex container with its content vertically centred. This works perfectly when the content is totally contained within the body element.
When the c...I stumbled upon this bug while working on !15.
Currently the body element is a 100% high flex container with its content vertically centred. This works perfectly when the content is totally contained within the body element.
When the content grows taller than the body element, however, it leads to a situation where part of the content flows out of the top of the viewport and cannot be scrolled to, as demonstrated in this plunk https://plnkr.co/edit/tqAf08kTLTE2miz2?open=lib%2Fscript.js&preview.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/28Make some cosmetic tweaks to the form to foil spam accounts2024-03-11T12:23:38ZNick MathewsonMake some cosmetic tweaks to the form to foil spam accountsHere are a few things we could do to the main "create an account" form that might discourage automated spam:
* Rename the "reason" field to something that spambots will fill in some other way, like "address" or "zip" or ""
* Add a n...Here are a few things we could do to the main "create an account" form that might discourage automated spam:
* Rename the "reason" field to something that spambots will fill in some other way, like "address" or "zip" or ""
* Add a name field that gets hidden via CSS; if it gets filled in, the request should get rejected.
* Change the example 'reason' from "I wish to report an issue in Tor Browser" to something less likely, like "I wish to report an issue in the TorCtl library."https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/27Prefer the in-built unique option to custom unique validator2021-05-03T13:42:16ZmfonismPrefer the in-built unique option to custom unique validatorWe're currently using a custom validator to enforce uniqueness of usernames in lobby requests. Django already provides the option `django.models.fields.Field.unique`, and in the spirit of DRY we should be using this.We're currently using a custom validator to enforce uniqueness of usernames in lobby requests. Django already provides the option `django.models.fields.Field.unique`, and in the spirit of DRY we should be using this.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/17Make separate settings.py file for production and development2023-08-10T19:10:13Zasu1996Make separate settings.py file for production and developmentWe can add separate settings.py file for production and development and use python-decouple to increase the security of certain elements.
Also, separate files can help in preventing really long settings file
This can be an extension to...We can add separate settings.py file for production and development and use python-decouple to increase the security of certain elements.
Also, separate files can help in preventing really long settings file
This can be an extension to #5
Opinions on this? @ahf @gabahttps://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/18Bulk approval seems to have stopped working2023-08-10T19:10:13ZNick MathewsonBulk approval seems to have stopped workingI just tried to approve some accounts from the admin page, and nothing changed. I had to approve them one by one from the individual request pages instead.
This was roughly 1 minute ago, in case the timestamp is helpful. :)I just tried to approve some accounts from the admin page, and nothing changed. I had to approve them one by one from the individual request pages instead.
This was roughly 1 minute ago, in case the timestamp is helpful. :)https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/19Remember who approved a request, and when.2023-08-10T19:10:13ZNick MathewsonRemember who approved a request, and when.It would be good to display, along with each approved request, the admin who approved it, and when. That way, we can ask each other, "hey, why did you approve such-and-such"?
This would need a corresponding database change, unless we'r...It would be good to display, along with each approved request, the admin who approved it, and when. That way, we can ask each other, "hey, why did you approve such-and-such"?
This would need a corresponding database change, unless we're already storing this.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/21Separate status for not-yet-approved-or-rejected requests2023-08-10T19:10:13ZNick MathewsonSeparate status for not-yet-approved-or-rejected requestsRight now, every request begins life in a "no" state and may become "yes" if anybody approves it.
Instead, I think requests should begin in a "pending" state, and require an admin to set them to "no" or "yes".
There should be no behavi...Right now, every request begins life in a "no" state and may become "yes" if anybody approves it.
Instead, I think requests should begin in a "pending" state, and require an admin to set them to "no" or "yes".
There should be no behavior difference between "pending" and "no" for now -- this feature would just be a way to distinguish between requests that nobody has looked at, and requests that somebody has looked at and rejected for now.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/22Notify admins if any request is pending for more than N hours2023-08-10T19:10:13ZNick MathewsonNotify admins if any request is pending for more than N hoursOnce #21 is done, it would be good to have a feature to notify the admins if there are any requests that have sat around for a long time without being approved or rejected.Once #21 is done, it would be good to have a feature to notify the admins if there are any requests that have sat around for a long time without being approved or rejected.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/23Automatically delete (or archive?) approved or denied requests after N days2023-08-10T19:10:13ZNick MathewsonAutomatically delete (or archive?) approved or denied requests after N daysOnce #21 is done, it would be handy to not have to delete requests by hand. Instead, there should be some mechanism that automatically deletes or archives requests after they have been approved or rejected for some number of days (say, ...Once #21 is done, it would be handy to not have to delete requests by hand. Instead, there should be some mechanism that automatically deletes or archives requests after they have been approved or rejected for some number of days (say, 7). The number should be configurable.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/24Add the ability to ask questions about a request2023-08-10T19:10:12ZNick MathewsonAdd the ability to ask questions about a requestThis is a harder item than some of the other tickets I've created; it's more of a wishlist thing.
It might be nice if instead of rejecting or accepting a request, admins could ask, "huh"? For example, consider a request that just says ...This is a harder item than some of the other tickets I've created; it's more of a wishlist thing.
It might be nice if instead of rejecting or accepting a request, admins could ask, "huh"? For example, consider a request that just says "trying to log in" Is that a real request? Did the user not understand what the instructions said? Or is it just automated spam?
If we had a feature like this, it would probably need to go along with a feature for users to edit their requests or cancel them.https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/25Track average time between request and response, and tell users when they mak...2023-08-10T19:10:13ZNick MathewsonTrack average time between request and response, and tell users when they make their requestIf we remember how long it takes for the average approved request to _get_ approved (#19) we can give users a useful message when they make their request. Maybe something like, "M% of requests are approved within N hours."If we remember how long it takes for the average approved request to _get_ approved (#19) we can give users a useful message when they make their request. Maybe something like, "M% of requests are approved within N hours."https://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/29Add championquizzer to the admin for the gitlab lobby2022-04-04T23:08:22ZGabagaba@torproject.orgAdd championquizzer to the admin for the gitlab lobbyAdd championquizzer so he can approve gitlab accounts.Add championquizzer so he can approve gitlab accounts.Gabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/tpa/gitlab-lobby/-/issues/20Add an admin-only "notes" field to requests2024-02-14T09:43:28ZNick MathewsonAdd an admin-only "notes" field to requestsRight now if we want to make notes on a request we need to edit the request. That's error-prone and eventually will create problems.
Instead, each request should have a separate "notes" field. Only admins should be able to review and ...Right now if we want to make notes on a request we need to edit the request. That's error-prone and eventually will create problems.
Instead, each request should have a separate "notes" field. Only admins should be able to review and edit this field.jugajuga