Im making a photo gallery application where users can only see their own
photos.
My photos table looks like this
Id, PhotoName, PhotoURL, PhotoUser

I need to know how I can integrate this with ASP.NET's membership provider
Can someone points me to the right direction

Thanks

Tem

You'll need to create your own custom provider if you wish to manage, not
only the users & roles but also the photo data.

http://www.devx.com/asp/Article/29256




"Tem" <tem1232 (AT) yahoo (DOT) com> wrote

On 27 Dec, 20:39, "Tem" <tem1... (AT) yahoo (DOT) com> wrote:
I'm not sure what you mean by "integrate" but the requirement you
describe could be met by filtering the data table on Membership
username (if that differs from PhotoUser then add an extra column)
which is easily read with the Membership.getuser() function.

Thanks

If I understand this correctly PhotoUser would store the username of the
user the photo belongs to. Wouldn't this be slow performance wise?
(searching a string)
would it be faster to use UserID uniqueidentifier instead?

"Phil H" <google (AT) philphall (DOT) me.uk> wrote

Not if you indexed the PhotoUser column.

--
Mohamad Elarabi
MCP, MCTS, MCPD.


"Tem" wrote:

how would I do that?

"Mohamad Elarabi [MCPD]" <MohamadElarabiMCPD (AT) discussions (DOT) microsoft.com>
wrote in message news:5879D58F-89BB-4CA5-87E3-72723E871DB7 (AT) microsoft (DOT) com...

Believe me I tried. I have read those documentations and watched all the
video tutorials. They covered how to create login page, set up user profile,
web.config....none of them addressed what I'm trying to do.
that is why I posted my question here. maybe im not reading them correctly,
if you can point me to the right direction that would be really helpful.

Tem

"clintonG" <nobody (AT) nowhere (DOT) com> wrote

I think you may be confusing what the Membership and Role provider can do.

Lets take a generic example.

I work at a hospital.

There are a few roles.

VP
HR
Worker


Let's say there is a business rule which says...
VP can delete employees under them.
HR can delete any employee.
Worker can't delete anybody.

So maybe here is a webpage called

employeedelete.aspx

look at the vp rule. even though the vp can delete employees...he/she can
only delete CERTAIN employees, not all employees.
thus when the vp visits the page "employeedelete.aspx"...only a handful of
emp's should show up.

the filtering is NOT handled by the membership or role provider. you have
to do that.

being able to see employeedelete.aspx in the sitemap, being able to visit
employeedelete.aspx page, that is (kinda) handled via the 2 providers.

so your "can see my images" rule is like the VP deleting employees. the
user can see images, but only his/her images. not everyones.

so the user (in role of "normaluser" for example) can get to a page called
imagesShowForUser.aspx
but YOU need to write the filtering code for which images show up here on
this page.

Membership is going to allow you to create users ... and all that jazz
(passwords, password reset, etc)...
Roles will allow you to put userX into a role (like "normalUser").

But you still need to code up the filtering for a user getting only his/her
images.






"Tem" <tem1232 (AT) yahoo (DOT) com> wrote

This is what I don't understand
How would it know, who the photo belongs to if there wasn't an identifier
field (PhotoUser) in the Photo table?



"sloan" <sloan (AT) ipass (DOT) net> wrote

On 28 Dec, 18:28, "clintonG" <nob... (AT) nowhere (DOT) com> wrote:
Speaking as one of those other than Mohamid who offered advice here I
would make the following observations:

(1) It is reasonable to suspect that the PhotoUser column is redundant
but without more information about background and context I was a
little cautious in suggesting it should be deleted.

(2) Yes it is true that loginViews can filter out various elements
according to identity and privelege but that is not the kind of
filtering that was being requested in this case. All that was asked
for is that the user only see records from a datasource that are
relevent to them personally. Ordinary row filtering is straight-
forward enough and probably simpler than constructing a LoginView type
control to meet that particular need (what are you going to do, create
an individual template for every user?).

I don't see any performance issues. If your application is data-driven
then the suggested solutions will not make it any worse.