Opened 19 years ago
Last modified 3 years ago
#1890 new defect
Can create tickets anonymously using the username of an authenticated user
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | high | Milestone: | next-major-releases |
| Component: | general | Version: | 0.8.4 |
| Severity: | major | Keywords: | authentication |
| Cc: | wkornew, ziggy@…, tkarakai@…, vyt@…, lievenswouter@…, dkg-debian.org@…, johnjaylward@…, jevans591@…, carsten.klein@…, Thijs Triemstra, leho@…, Jun Omae, Ryan J Ollos | Branch: | |
| Release Notes: | |||
| API Changes: | |||
| Internal Changes: | |||
Description (last modified by )
I can create tickets anonymously using usernames of registered users. This is a Bad Thing™ in that people can impersonate me on my Trac. Or, they could otherwise pretend to be me. Which, to some users, may be confusing and misleading. It also poses a security threat in that any random person can go in and meddle in my bugs and close at will because to be able to add a comment to a ticket, you have to have TICKET_MODIFY, which essentially means anonymous has TICKET_ADMIN (filing another bug for this, since I know that at least in my projects, I like two problems to be reported as… two problems…)
Current status of the discussion: each change to a ticket must also record whether the user who did the change was authenticated or not.
See more complete summary in comment:53.
Attachments (3)
Change History (88)
comment:1 by , 19 years ago
| Severity: | critical → normal |
|---|
comment:2 by , 19 years ago
Oh, okay. Well. The confusion issue is still important, especially if you're dealing with total idiots :).
comment:3 by , 19 years ago
It's not only confusing! Trac provides no way to see who really added a comment. So users with the same privileges can impersonate me, and there is no visable way not to believe it.
You think I am "mgood", as it appears above? Think twice… Can you tell my userid (assuming I logged in)? …this is just to show what we are talking about…
Can you at least add the actual username of the user in brackets if it is different from the name he wants to use, or something similar?
comment:5 by , 19 years ago
| Cc: | added |
|---|
comment:7 by , 19 years ago
| Milestone: | → 0.9 |
|---|
Could you at least include the minimal fix of ALWAYS showing the userid of the modifying person, if different from the name he wants to use (maybe in brackets) in the 0.9 release? Please?
comment:8 by , 19 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
Would be easier to raise an error if someone tried to use a name of a known authenticated user, if he's actually anonymous or another authenticated user.
comment:10 by , 19 years ago
Raising an error doesn't prevent identification problems (although it is better then what we have today).
What is the goal here? Is it for completely open projects, so anyone in the world can choose any identity at any time for privacy reasons? If anonymous access is allowed, why don't those who want to shield their identity log off and act as the anonymous user? Anonymous activity still should be clearly marked as such. Even then, some projects might want to record originating IP address and other clues if ID to discourage abuse. Once logged in, what's the point of changing identity?
Regardless, in closed environments (where no anonymous access allowed) there is no point of letting ANYBODY to appear as somebody else, so I would even remove the "Your email or username" field on editing pages entirely and just display the username. In these private project is is dangerous to let people change identities, especially if you need to find responsible persons later or if business client relationships are at stake.
As I suggested, as a fist step, in addition to the desired name typed in the actual user name should still ALWAYS be displayed (how hard is that to implement?) and loggen in users would need to log out to be able to appear someone else. If you are not logged in, the username displayed would be, obviously, "anonymous". This solution keeps privacy and can be still used in closed projects. Later we can think about real authentiction solutions, maybe optionally selectable by the site admin…
Note: Since currently is is not possible to log out without closing your browser, there are still some issues, but I have to assume that it will be solved soon. See #791 currently abandoned :(
comment:11 by , 19 years ago
Raising an error doesn't prevent identification problems (although it is better then what we have today).
Sure it does. The rest of your comment doesn't seem to back up this statement, or I'm not understanding you completely.
I do agree however that it doesn't make sense to allow authenticated users to change the name under which they perform edits. So the field should be hidden from them.
The reason for allowing anonymous users to set their username and email directly in the ticket/wiki form is to make it easy for them to e.g. submit a ticket and include their contact information. Of course we can't easily validate that the user entered their real email address. Forcing them register to first (possibly even including an email exchange for verification) is a good way to discourage folks from participating. So as long as Trac validates that the name/email used doesn't conflict with that of some authenticated user, I think that's a good enough approach for now.
comment:12 by , 19 years ago
- For an implementation that handles correctly this issue, look at phpBB. You can easily tell if someone was logged in or not when they posted, and still provides them with a way to change their names.
- Not all installations are open source. We, for example only allow logged in users to enter/modify tickets. So ideally, users would not be able to change their names at all. It'd be nice to have a flag to provide this behavior.
comment:13 by , 19 years ago
Raising an error doesn't prevent identification problems (although it is better then what we have today).
Explanation: I should have said "all identification problems". You are right, it prevents the most important ones: existing users cannot be impersonated. You could still make up and use non-existing user names and for those readers who don't know the list of valid users, it could still appear to be someone else, unless identified as "self-named".
Agreed to Anonymous' points written at 10/11/05 15:20:04.
comment:15 by , 19 years ago
| Cc: | added |
|---|
comment:16 by , 19 years ago
| Milestone: | 0.9.1 → 0.9.2 |
|---|
comment:17 by , 19 years ago
| Cc: | added |
|---|
The reason for allowing anonymous users to set their username and email directly in the ticket/wiki form is to make it easy for them to e.g. submit a ticket and include their contact information.
If this is why there's an editable field for anonymous users, then the value should be something resembling an email address, right? You wouldn't have to have a complex user registration and email verification process unless it was actually necessary to your setup. But a simple regexp would be a quick fix and useful to both completely open and completely closed setups.
This would prevent anons from masquerading as a registered user (or even as a username that might be registered in the future). It would not prevent registered users from masquerading as other users, but an appropriate fix to this second problem has already been pointed out — remove the editable text box.
comment:18 by , 19 years ago
| Cc: | added |
|---|
comment:19 by , 19 years ago
| Milestone: | 0.9.4 → 0.10 |
|---|
comment:20 by , 19 years ago
| Cc: | added |
|---|
comment:21 by , 19 years ago
The attachment 'authen.diff' I have made shows a basic way of closing this hole.
It performs two mappings on the author information:
If anonymous user:
author = '<author info from form field> [unauthenticated]'
Elif authenticated user:
If '<author info from form field>' == '<authenticated username>':
author = '<authenticated username>'
Else:
author = '<authenticated username> (<author info from form field>)'
I think I have probably broken emailing to ticket reporters, but at least it is a start towards a solution.
comment:22 by , 19 years ago
| Cc: | added |
|---|
comment:23 by , 18 years ago
I started writing a patch for this, which essentially just checks whether the username field in wiki/ticket/attachment pages is not another users username. This feels quite crufty though and I think it better to leave this until Trac has better/more flexible authentication.
comment:24 by , 18 years ago
Checking whether the username field is not another user's username falls apart for two reasons:
- If using HTTP authn done by the webserver, there's no way to reliably get a list of all valid usernames.
- A user could be created with the same name after a comment had been made.
comment:25 by , 18 years ago
What about a kind of flag saying that the user is authenticated or not.
For example, when recording an author (wiki edits, ticket comments), we store the user name enclosed in parenthesis if the session is not authenticated.
The "forged" comment:3 would then read Modified by (mgood).
It could then be clear for everyone that it's either mgood
(but not authenticated) or someone pretending to be him (as it was
the case, for demonstration purpose).
comment:26 by , 18 years ago
Parentheses for anonymous usernames would satisfy me - I'll tweak my patch appropriately.
Two points that need clarification:
- Presumably, special-case "anonymous" so that it doesn't get re-written to "(anonymous)" ?
- What about when an authenticated user edits the content of the username field? I favour simply removing the username textbox from the form, for authenticated users, and not accepting that CGI parameter in that case.
comment:27 by , 18 years ago
Replying to the above comment:
- I'd say, why not keep "(anonymous)", for consistency; otherwise you'd quickly get questions about this, like I thought I got it, the (…) are indicators of a non-authenticated users, but it must not be that, as "anonymous" don't have those and is most certainly not an authenticated user…
- yeah right, removing the Your email or username field for authenticated users makes sense.
Thanks for working on a patch.
comment:28 by , 18 years ago
I really don't think it's a good idea to modify the username before storing it into the database. It seems to me the potential for side-effects is quite large. Two examples off the top of my head are notifications and the default query page. Notification will expect the comment author to be a valid username and will have to be modified to strip the parentheses, while the query page will have to add parentheses before doing its matching.
The other issue of course, is plugins. No plugins will have knowledge of this username format, for either querying or modifying.
Reiterating my previous statement: this feels quite crufty and I think it better to leave this until Trac has better/more flexible authentication.
PS. cboos, have you noticed the patch attached to this ticket displays only two files from the diff?
comment:29 by , 18 years ago
Re: cruftiness
Yes, I suppose it is. OK, a less crufty way to do it would be to modify the SQL schema - perhaps add an 'authenticated' boolean alongside the fields:
- attachment.author
- ticket.reporter
- ticket_change.author
- wiki.author
Would that be an acceptable solution?
by , 18 years ago
| Attachment: | authentic.patch added |
|---|
Patch vs. 0.9.5 (implementing the crufty solution) that I am currently using as a workaround on my production installation. [OBSOLETES: authen.diff]
comment:30 by , 18 years ago
[OT]: Patch renderer
Replying to alect about attachment:authen.diff: I think that this patch is slightly broken and that's why it's not correctly rendered. Adding a newline here and there makes it viewable. I'll have a look if I can make the patch renderer a tad more robust.
Then there's the attachment:authentic.patch, which contains a changelog, and I think that it would be a good idea that our patch renderer also shows this information. Mercurial exported changesets would also benefit from this improvement.
comment:31 by , 18 years ago
Back to the topic: well, adding the parenthesis was just one implementation idea, I expected it to be not intrusive but you proved me wrong.
The important point however is about the approach: I think what matters is to record whether a particular contributor is authenticated or not at the time she made the contribution, not if the username is a valid one or not. As others said, the list of users might change over time or a username can be made to look like the one of a valid user.
So adding an authenticated flag alongside the author field would
be a solution. A slightly less intrusive approach would be to reuse
the ipnr field already present in the wiki and attachment table:
as I believe that this information is not really relevant for
authenticated users, why not set it to NULL as a way to flag
the contributor as being authenticated?
The schema changes needed would be simply to add the ipnr field
to ticket and ticket_change, which would at the same time make
things more consistent with the Wiki (i.e. recording the IPNR
for non-authenticated users) and provide a way to fix this issue.
Independantly of the above, I'd also propose that we merge the disabling of the Your email or username field for authenticated users provided in attachment:authentic.patch.
comment:32 by , 18 years ago
Schema: Since some sort of schema change is needed, I'd prefer a dedicated field rather than overloading ipnr in a non-obvious way. Whilst I agree that ipnr is not as important for authenticated users, I'm not sure that it is completely irrelevant.
Disabling of the Your email or username field for authenticated users: I will port that portion of the patch to trunk.
Additional concern for Query Builder: It will need a way to add a search criterion of 'Reporter is/is not authenticated'.
Additional concern for notifications: Might someone want the ability to only send emails to authenticated reporters/commenters?
by , 18 years ago
| Attachment: | 1890-firststeps.patch added |
|---|
Patch vs. trunk@3391 to fix the easy part of this issue: hide the username box for authenticated users, and make equivalent changes to the .py files so that stale templates or malicious users cannot change the behaviour.
comment:33 by , 18 years ago
The problem I see with adding new columns per username (eg. is_authenticated or whatever) is that this rapidly explodes. 5 or 6 extra columns would have to be added to Trac itself, not to mention plugins recording similar information.
I can think of at least two options that are preferable IMO:
- Require anonymous users to enter an E-Mail address or the username anonymous. Do not allow them to enter an arbitrary username. eg.
Alec Thomas <alec@swapoff.org>would be stored in my anonymous session. - Switch to a more concrete concept of identity in Trac. Form based login + registration. This is not an uncommon model and, in fact, Roundup looks to use it from the dabbling I've done. This would probably be a controversial choice however, given Trac's history of openness.
comment:34 by , 18 years ago
I seriously favor the registration model. For my project I switched from Mantis to Trac, mainly because of the advanmced subversion integration, roadmap, timeline and milestone features. The lack of user registration is however a serious drawback.
comment:35 by , 18 years ago
Have you tried th:wiki:AccountManagerPlugin? It allows user registration. That in conjunction with disabling anonymous edits may meet your requirements.
comment:36 by , 18 years ago
| Keywords: | review added |
|---|
Add keyword review, with respect to attachment:1890-firststeps.patch.
comment:37 by , 18 years ago
| Cc: | added |
|---|
comment:39 by , 18 years ago
Please remove the "Your name" field when someone is logged in. The interface should be optimized for the most common use-cases and there is really no need to show it when logged in, apart from the 1% case that you have multiple logins, but there are alternatives to make this easier (e.g.: write username in "logged in as …" in bold).
comment:40 by , 18 years ago
| Cc: | added |
|---|
comment:41 by , 18 years ago
An is_authenticated field attached to the various username fields is the right way to go, IMHO. The lack of this information is really the main drawback to trac at the moment.
This would need to be combined with removing the e-mail/username box for authenticated users and ignoring that CGI variable while authenticated, as suggested in comment:27. Deciding how this information is displayed (parentheses, a funny color, whatever) is a pretty trivial discussion compared to the information being stored cleanly and explicitly in the DB the first place.
Trac's deferral to the web server for authentication is a great feature, and i would be very disappointed to see trac try to implement the login mechanism itself, thereby losing the wonderful flexibility that all the various apache authn modules provide.
follow-up: 43 comment:42 by , 18 years ago
1890-firststeps.patch applied in r3461.
It seems that we're going to have an authenticated field, after all…
About r3461: do we really need to tell the world about the email address? Maybe we could store two e-mails in the settings, public and private. Use either one for the notifications, but only display the public one if given.
follow-ups: 44 45 comment:43 by , 18 years ago
Replying to cboos:
About r3461: do we really need to tell the world about the email address? Maybe we could store two e-mails in the settings, public and private. Use either one for the notifications, but only display the public one if given.
No, this adds unnecessary complication. The users' email addresses should only be visible to admins and developers (TICKET_MODIFY?) by making the username a link to the email address. The email address itself should be stored in the database (instead of session) and the Cc field should be replaced with a simple "Watch this ticket"/"Stop watching this ticket" link. No more publicly accessible email addresses (we have enough SPAM!). This seems to be planned for 0.12, anyway, but I think that this is important enough to find its way into 0.11 together with real user management and public registration with username, password, email. That would finally make Trac usable for big projects (we'd still need improved queries, though).
comment:44 by , 18 years ago
Replying to anonymous:
.. and the Cc field should be replaced with a simple "Watch this ticket"/"Stop watching this ticket" link.
Such a link is a good idea but it's not suitable. Very often I CC owners of other components if I want there comments on the issue. This is a common interaction model that relies on the email sending but it's quite convenient.
comment:45 by , 18 years ago
Replying to anonymous:
I think that this is important enough to find its way into 0.11 together with real user management and public registration with username, password, email.
Please don't force these features into Trac. Lots of "big projects" already have user databases, and don't need a whole new one just for their tracking system.
If someone wants to write an optional user-management module that connects to some external database/whatever to implement public registration, etc, that'd be fine. But please don't assume that we all want Trac to keep its own set of user accounts and authenticators.
follow-up: 51 comment:46 by , 18 years ago
| Milestone: | 0.10 → 0.11 |
|---|---|
| Owner: | changed from to |
| Status: | assigned → new |
About the authenticated column:
See a TracDev/JournalingProposal#Asolution, in which I propose
to have two tables for storing ticket changes: ticket_transaction
for meta-data about the change, identified by tid
and the ticket_change table would contain the actual field
changes. There would be a 1 -> n relationship between them,
so this would make it acceptable to store additional changes
like authenticated and ipnr without introducing too much
complexity and redundancy.
follow-ups: 48 50 comment:47 by , 18 years ago
Gunnar: Well, if we allow admins to edit the list of users watching a ticket this would solve.
dkg-debian.org: About user-management: of course, this may be optional, but we really need a unified and pluggable way to associate meta-data with users (email, password, real name). The current session mechanism is terrible.
follow-up: 49 comment:48 by , 18 years ago
Replying to wkornew:
Gunnar: Well, if we allow admins to edit the list of users watching a ticket this would solve.
No, that would be a too big influence in the workflow and usability. Imagine the stabilization weeks after a code freeze. Every check-in needs a ticket and every ticket needs (depending on time, impact, etc.) one or mode votes from lead developers. So now think what my guys would say if they have to ask an admin 8 times a day to cc some lead developers on any issue.
comment:49 by , 18 years ago
Replying to gunnar <g>:
No, that would be a too big influence in the workflow and usability. Imagine the stabilization weeks after a code freeze. Every check-in needs a ticket and every ticket needs (depending on time, impact, etc.) one or mode votes from lead developers. So now think what my guys would say if they have to ask an admin 8 times a day to cc some lead developers on any issue.
Well, you could allow all developers to access that list, too. I was just suggesting that this list could still be editable, but normal users must not get access to it. BTW, the subscribers list should be hidden, by default, and require some action to become visible.
comment:50 by , 18 years ago
Replying to wkornew:
dkg-debian.org: About user-management: of course, this may be optional, but we really need a unified and pluggable way to associate meta-data with users (email, password, real name). The current session mechanism is terrible.
I understand your desire. i don't really have a problem with Trac keeping additional metadata tagged to a username. In fact it already does: for example, you can see how many tickets were opened by a particular username; that's a type of metadata.
What i'm objecting to is the idea of moving the canonical list of usernames and their associated authenticators (usually passwords) into Trac itself. Trac ought to gracefully handle requests coming from authenticated user names (as passed to it from apache) even if it has never seen the username before. If your proposed user-metadata table would not choke in the face of a novel username, i have no problem with it.
Note that this precludes Trac doing any management of authentication tokens on its own. (i.e. do not store passwords in the user-metadata table). How would Trac authenticate a username properly if it had no record of it before?
The current session mechanism is not terrible; it is actually extremely flexible. Trac is one of the few projects out there that uses apache's myriad authentication possibilities correctly, from what i can tell. My goal here is to avoid Trac becoming YAUDB (yet another user database) that admins of a large project need to tweak by hand to keep in sync with some truly-canonical centralized listing. The current mechanism handles this situation simply and elegantly, with no ongoing work on the admin's part. (though getting that is_authenticated field will be nice).
follow-up: 52 comment:51 by , 18 years ago
Replying to cboos:
About the
authenticatedcolumn:
Your note on this ticket seems to imply that is_authenticated would live in one of the n ticket_change (or property_change, in the generalized case) records associated with the ticket_transaction (or journal), but the linked page (actually TracDev/Proposals/Journaling) puts is_authenticated in the journal table. I prefer it in the journal table.
If this is where is_authenticated is going to live, it really needs to be handled for the generalized case, though. We don't just need to know "who did this" for tickets. It's useful for everything.
I'm also not familiar with Trac's db schema enough to know how straightforward it would be to tie the journal record to a specific version of an item. Doing so would be necessary, of course, to actually present this data back to the client at pageview. If this is an obvious, simple SQL call, forgive my ignorance. If it's non-trivial, i'd be interested in seeing a proposal for how to extract the is_authenticated flag for, say, each comment in a ticket.
comment:52 by , 18 years ago
Replying to dkg-debian.org@fifthhorseman.net:
Replying to cboos:
About the
authenticatedcolumn:Your note on this ticket seems to imply that
is_authenticatedwould live in one of the nticket_change
Sorry for being unclear then, I really meant to say that is_authenticated (or simply authenticated) should be part of the journal table.
If this is where
is_authenticatedis going to live, it really needs to be handled for the generalized case, though. We don't just need to know "who did this" for tickets. It's useful for everything.
Well, yes. That was the idea, every state change in the system is a priori done by some user, at one given point in time. Storing that kind of information differently, redundantly and/or partially as it's done now is a bit counter-productive.
… how to extract the is_authenticated flag for, say, each comment in a ticket.
E.g. with a property_change and journal tables, like suggested in TracDev/Proposals/Journaling:
cursor.execute("SELECT j.author, j.authenticated, j.ipnr, j.time, p.newvalue " " FROM property_change p " " INNER JOIN journal j ON j.tid=p.tid" " WHERE j.type='ticket' AND j.id=? " " AND p.field='comment' " " ORDER BY j.time", (ticket_id,)) for author,auth,ipnr,time,comment in cursor: print "%s by %s (%s) %s\n\n%s\n----\n" % \ (time, author, ipnr, auth and '[authentified]' or '', comment)
For Wiki page versions, that's a slightly different matter. Right now, the authenticated column could simply be added to the wiki table, as there's anyway one row for each different version.
But in the future, even this could be improved.
comment:53 by , 18 years ago
| Keywords: | review removed |
|---|
![Clearing 'review' keyword, as the patch it applied to has been committed]
A significant subset of the recent discussion has been only peripherally related to the subject of this ticket, leading to a very long string of comments that don't have much bearing on fixing this defect. I would like to suggest that any further debate on authentication philosophy take place elsewhere, perhaps on a mailing list, or at least in another ticket. I will attempt to summarize current status, so that there is a concise statement of what action remains to be taken regarding this ticket.
Summary of ticket status at this point
TracDev/Proposals/Journaling (IMO) outlines the correct long-term goal, and it may be appropriate to file an 'implement that proposal' ticket at some future point.
In the shorter term, to resolve this ticket, and as a stepping stone on the path to implementing that proposal, I think we should add is_authenticated fields alongside every current author or reporter field (in the same tables), and arrange for that information to be set and displayed as appropriate.
This will allow work to proceed in making the wiki and ticket subsystems collect, store, display, and use the is_authenticated information immediately, to get this ticket fixed for milestone:0.11.
This is in no way a step in a different direction to the journalling proposal, rather it is a preparatory step to make it easier to implement in the future: when the time comes to implement it, that work will be aided if all the disparate subsystems are already handling all the relevant fields, and it is only the database interaction code that needs changes, rather than the processing and display logic too.
comment:55 by , 18 years ago
| Cc: | added |
|---|
comment:68 by , 18 years ago
| Cc: | removed |
|---|
comment:73 by , 18 years ago
| Cc: | removed |
|---|
comment:75 by , 18 years ago
| Cc: | removed |
|---|---|
| Type: | → defect |
I'm fed up of the spam. Going off the CC list.
comment:76 by , 18 years ago
comment:77 by , 18 years ago
| Milestone: | 0.11 → 0.12 |
|---|
comment:79 by , 18 years ago
| Cc: | added |
|---|
follow-up: 85 comment:80 by , 15 years ago
| Cc: | added |
|---|
Is this a variation of the same issue?
We don't allow anonymous access, but we do have people that sometimes need to enter tickets for other people. We want to enter the true reporter in the Reporter field but would also like be able to tell who entered the ticket.
Instead of an is_authenticated field, we'd like to see Trac record both the entered reporter and the current login. When they're different, do something like adding the login to the 'Opened <some time> ago by <login>'.
comment:81 by , 15 years ago
Ok, I am not cboos, just returning to this ticket after 4 years… Seeing that it is kept being postponed indefinitely, currently to v 0.13, is kinda disappointing… I guess it is not a priority… Just wanted to know…
comment:82 by , 15 years ago
Are there any plans to see this happening at all in v0.11.7? I am currently running on 0.11.5 and am eager for 0.11.7 to be released.
However, this login issue is a major concern with our customers & support desk. Really wish i knew more about programming in python so i could help contribute to this project & provide a quick patch.
comment:83 by , 15 years ago
| Keywords: | authentication added |
|---|---|
| Priority: | normal → high |
| Severity: | normal → major |
Well, #1890 is not about a quick patch, otherwise it would have been fixed earlier obviously.
It's true that there are still some important tickets that are now aging, 4 or even 5 years, which is not to say that we don't think they're not worth implementing, simply the occasion to deal with them seriously hasn't occurred yet. Just look at the amount of issues (small or big) that get done to persuade you that the project is still alive and doing well. Now if only a few more people would consider to actively contribute (we're currently 2 regular contributors), the situation could be sensibly different.
comment:84 by , 15 years ago
| Cc: | added |
|---|
follow-up: 88 comment:85 by , 15 years ago
Replying to jevans:
We don't allow anonymous access, but we do have people that sometimes need to enter tickets for other people. We want to enter the true reporter in the Reporter field but would also like be able to tell who entered the ticket.
Please use a custom field for this. See TracTicketsCustomFields for more information on this.
follow-up: 87 comment:86 by , 15 years ago
How about this on ticket _do_save():
authname = req.authname
reporter = ticket.author
if authname == 'anonymous':
if settings.email != reporter:
will fail with notice that user must first configure his or her
preferences (general/email)
upon saving the settings, it must check whether there is a
similar (i.e. the same) email already registered with the system,
if so, the user must confirm his or her authenticity (1)
else if authname != 'anonymous':
we are clear here since the authenticated user cannot modify the
author field, however that must also be explicitly programmed into
populate_data since otherwise one might forge POST requests in order
to impersonate a different person on SUBMIT.
(1) user might consider taking over the registered settings/email, by having
himself being sent a confirmation mail that he then must receive in order to
follow the confirmation link. the link itself will have a random key generated
by the system and associated with a settings/email take over request.
comment:87 by , 15 years ago
Replying to Carsten Klein <carsten.klein@…>:
(1) user might consider taking over the registered settings/email, by having himself being sent a confirmation mail that he then must receive in order to follow the confirmation link. the link itself will have a random key generated by the system and associated with a settings/email take over request.
Of course, the email will be sent to the email address registered with the system that the user wants to take over.
Sample email
Dear Trac User, you have requested that you want your settings, registered with the email address "foobar@random.house", be associated with a new cookie installed into your user agent. Please confirm using this link http://trac.example.com?key=AE32_12v432 If you have received this mail without having requested it, you can safely ignore this mail. Regards, Your Trac Team
Of course the mail would have to be customized with the project's name and so on.
follow-up: 89 comment:88 by , 15 years ago
Replying to Carsten Klein <carsten.klein@…>:
Replying to jevans:
We don't allow anonymous access, but we do have people that sometimes need to enter tickets for other people. We want to enter the true reporter in the Reporter field but would also like be able to tell who entered the ticket.
Please use a custom field for this. See TracTicketsCustomFields for more information on this.
So then you have two 'reporter' fields and create confusion over how to fill out a ticket…
follow-up: 91 comment:89 by , 15 years ago
Replying to jevans:
Replying to Carsten Klein <carsten.klein@…>:
Replying to jevans:
We don't allow anonymous access, but we do have people that sometimes need to enter tickets for other people. We want to enter the true reporter in the Reporter field but would also like be able to tell who entered the ticket.
Please use a custom field for this. See TracTicketsCustomFields for more information on this.
So then you have two 'reporter' fields and create confusion over how to fill out a ticket…
Just don't name it reporter then. Perhaps 'purported by' or something like that would serve your purpose?
comment:90 by , 14 years ago
| Cc: | added |
|---|
comment:91 by , 14 years ago
Replying to Carsten Klein <carsten.klein@…>:
Replying to jevans:
Replying to Carsten Klein <carsten.klein@…>:
Replying to jevans:
We don't allow anonymous access, but we do have people that sometimes need to enter tickets for other people. We want to enter the true reporter in the Reporter field but would also like be able to tell who entered the ticket.
Please use a custom field for this. See TracTicketsCustomFields for more information on this.
So then you have two 'reporter' fields and create confusion over how to fill out a ticket…
Just don't name it reporter then. Perhaps 'purported by' or something like that would serve your purpose?
And then find a way to explain what 'purported by' means to your average user (or whatever the extra (unnecessary) field were to be called) — as I said, such an approach just adds confusion.
We already have the 'Reported by' field that already defaults to the user's login. Trac already knows whether the user is logged in, and if so as whom. To me, the elegant solution would be to make use of this information by displaying it somewhere when it doesn't match, such as "Opened 5 years ago by notziggy@…".
comment:93 by , 11 years ago
| Cc: | added |
|---|
comment:94 by , 11 years ago
I know we have format_author() from trac.web.chrome. May I suggest
- using this code more universally based on recorded tuples (session_id, is_authenticated) for author
- introducing a three-fold presentation approach like follows
- Mr. Somebody
- authenticated user
- Mr. Nobody
- some anonymous person pretending to be someone
anonymous
the infamous default label for a really anonymous author - even localized, if Babel and a suitable translation are available
OR, more radically, enforce saving 'anonymous' for any change record saved in an anonymous session. Rationale:
- clearly does not block anonymous contribution, granted that is is allowed by local policy
- helps keeping records more unambiguous (not pretending to know more that what is assured by authentication)
- even encouraging users to register (allowed by local policy again)
comment:95 by , 11 years ago
| Cc: | added |
|---|
comment:96 by , 11 years ago
We've reached what could become an easy and fast, yet sufficient solution in th:#11622. Comments welcome.
comment:97 by , 10 years ago
| Owner: | removed |
|---|
comment:98 by , 9 years ago
| Cc: | added |
|---|
Yes this could lead to confusion, but it does not give the user any ability to escalate their privileges. The name submitted in the ticket form is in no way used to determine their privileges, so there's no security risk here.