Users' access to fields from Profile module is not checked.

This should probably be done with access() in a new handler that takes care of all profile fields, which the current profile fields can inherit from.

Comments

merlinofchaos’s picture

merlinofchaos commented

The problem is that if you do that, the fields become always invisible, all the time. That makes it impossible for the administrator to set up a field that's excluded from the normal profile page, yet visible in a view.

dawehner’s picture

dawehner
Primary language German
commented

So is this a won't fix?

Alternative it could be configurable.

joachim’s picture

joachim commented

Yup -- we could add a handler to take care of all profile fields, with an option to either obey that field's privacy setting or not.

dawehner’s picture

dawehner
Primary language German
commented

The problem is that profile fields uses different handlers for different data.

joachim’s picture

joachim commented

Make a new common class for them all to inherit from.

joachim’s picture

joachim commented

... ugh, except loads and loads of fields for Profile module use core Views handlers.

dawehner’s picture

dawehner
Primary language German
commented

That's what i meant.

joachim’s picture

joachim commented

Yeah, sorry. On holiday and didn't have access to the code.

How do we handle CCK fields that have field permissions?

dawehner’s picture

dawehner
Primary language German
commented

Sorry what's holiday, i don't understand this word.

Beside that fact that there is afaik no access check cck implements nearly each handler: argument/filter/sort/relationship for the basic data types again.

joachim’s picture

joachim commented

So it does.

But content_handler_field has nothing about access at all.

This suggests to me we should think about something like an access callback property on field definitions.

dawehner’s picture

dawehner
Primary language German
commented

There is already a access callback and access arguments on views_data but it does not help because it's not configurable

Letharion’s picture

Letharion commented
Assigned: Unassigned » dawehner
Priority: Critical » Normal

I can't determine what needs to be done, but it doesn't sound "critical", so I'm demoting that, and assigning it to dereine, since he seems to be involved the most. :)

dawehner’s picture

dawehner
Primary language German
commented
Assigned: dawehner » Unassigned
Category: bug » task

This is more like a task.

joachim’s picture

joachim commented

The reason this was a bug and critical is that it can result in sensitive data being exposed...

dawehner’s picture

dawehner
Primary language German
commented

You run into many more serious problems if you run the profile module ;)

joachim’s picture

joachim commented

Well, not security problems... it's a bit crusty but it's not evil.

seaneffel’s picture

seaneffel commented

I bet if this issue were resolved in a way that Views respected the privacy settings of profile fields, then this other issue would come closer to being resolved as well:

http://drupal.org/node/311301

mustanggb’s picture

mustanggb commented
Issue summary: View changes
Status: Active » Closed (won't fix)