Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Be more careful about who gets "authority" privileges #427

Closed
hsenag opened this issue Feb 14, 2012 · 9 comments
Closed

Be more careful about who gets "authority" privileges #427

hsenag opened this issue Feb 14, 2012 · 9 comments
Labels
easier-admin Make issues easier to resolve f:request-management improvement Improves existing functionality (UI tweaks, refactoring, performance, etc) stale Issues with no activity for 12 months user-experience
Milestone

Comments

@hsenag
Copy link
Collaborator

hsenag commented Feb 14, 2012

Currently anyone with an email address @ the same domain as the FOI address can do special things on behalf of the authority. This goes wrong for small councils that use personal email accounts instead of having their own domain - e.g. anyone @gmail.com could upload to some councils.

This will also become more of a risk if and when we open up more features to the authority.

A few ideas for fixing this

  • don't apply the logic to .com addresses
  • have a blacklist somewhere of domains the logic doesn't apply to
  • add a field to the authority page for specifying the domain to accept with "[none]" or similar to disable, and default to the current logic and/or some of the other proposals
@RichardTaylor
Copy link

Has this been closed because it has been fixed?

Or because it's related to #41?

@sebbacon sebbacon reopened this Feb 14, 2012
@sebbacon
Copy link
Contributor

Because the UI makes it too easy to close things!

@confirmordeny
Copy link
Collaborator

.ac.uk addresses are also a risk because students may be given [email protected]

@garethrees garethrees added f:request-management improvement Improves existing functionality (UI tweaks, refactoring, performance, etc) labels May 29, 2018
@MattK1234
Copy link
Collaborator

Just to note we're dealing with a case on WhatDoTheyKnow at the moment where this would have helped.

The user was able to use their @institution.ac.uk email address to respond maliciously to requests to that institution. Such responses were published on WhatDoTheyKnow and appeared as if they had been sent by the institution.

@garethrees
Copy link
Member

Had a clear-out of my pinboard over the weekend so scanned the notes I made on this.

Doc

@RichardTaylor
Copy link

+1

This has understandably confused a poor Parish clerk today who was confused as to why WhatDoTheyKnow only offered the reply via WhatDoTheyKnow.com option to those with a googlemail address (the Parish council request address was @googlemail.com )

On a very closely related point we should stop calculated home pages eg. googlemail.com

Do we need a list of exceptions ?

This could be assembled from a list of the most common domains used in request addresses, presumably after excluding .ac.uk/.nhs.uk/gov.uk then hotmail / aol / gmail / outlook would come top and we could treat the latter specially?

@mdeuk
Copy link
Collaborator

mdeuk commented Aug 4, 2021

On a very closely related point we should stop calculated home pages eg. googlemail.com

Do we need a list of exceptions ?

This could be assembled from a list of the most common domains used in request addresses, presumably after excluding .ac.uk/.nhs.uk/gov.uk then hotmail / aol / gmail / outlook would come top and we could treat the latter specially?

I've split this into #6434 as it's definitely an issue in its own right - and it's one that is a nuisance not only for Alavateli admins, but for re-users of our data.

@garethrees
Copy link
Member

We now list over 8000 parish councils on WDTK. Many (1000s) have gmail, hotmail, outlook, btinternet, etc email addresses.

@HelenWDTK
Copy link
Contributor

This issue has been automatically closed due to a lack of discussion or resolution for over 12 months.
Should we decide to revisit this issue in the future, it can be reopened.

@HelenWDTK HelenWDTK closed this as not planned Won't fix, can't repro, duplicate, stale Nov 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
easier-admin Make issues easier to resolve f:request-management improvement Improves existing functionality (UI tweaks, refactoring, performance, etc) stale Issues with no activity for 12 months user-experience
Projects
None yet
Development

No branches or pull requests

10 participants