Request for comment: deprecating user profile

[Sashko Stubailo]

Hi meteor-core!

Recently I've been noticing a lot of cases of developers misusing the `profile` field on user documents. In particular, new developers that I've talked to during devshop or people asking questions on stack overflow tend to put everything, even secret keys and data that shouldn't be editable, on the `profile` field. We do document that it's user writable, but it's easy to miss that.

I've written up a hackpad about the issue with a proposal for removing this special-cased field: https://meteor.hackpad.com/Proposal-for-deprecating-user-profile-3UljX1VayvV

I want to get some feedback about this idea - are there legitimate use cases for user.profile that I'm missing? Do a lot of developers out there use it? Or is it just a bug-prone feature that new users can easily get caught on? Please leave comments on the Hackpad or reply here.

Thanks,

Sashko

[Stephan Hochhaus]

Hello Sashko,

I am using the profile field rather often and find it very comfortable to use. On the other hand I am not a big fan of multiple small exceptions that make the overall picture more complicated to grasp.

That said I feel removing the special treatment of profile is a good move. Especially if we can introduce a (core or community) package like accounts-insecure-profile that will provide the functionality as we know it today. 

Cheers!

Stephan

[Marin Pranjić]

We have noticed that profile ignores allow/deny rules. While we don't store anything important there, we didn't expect it.
If this was documented somewhere, we missed it.
I would prefer not having such special cases / exceptions to the rules, especially because current behavior is so easy to implement.
I have read the proposal. Lgtm, but I wish there was a general solution when breaking backward compatibility.

For example, when doing meteor upgrade from version A to version B, it would automatically install packages that warn about breaking changes between versions. Warning would go off when developer does "meteor remove <package>". This would also keep the core cleaner (if package is done right).

Marin

[Steve]

The special case of being able to write freely into profile is awkward.

The special case of having profile (and other user data) published without having to do the corresponding subscribe is awkward.

The code you have to put in createUser (user.profile = options.profile) is awkward.

Maybe all this makes sense when you use accounts-facebook, but as a basic user of accounts-password, I feel the whole 'profile' thing is awkward.

[Gabriel Pugliese]

I think it does not make sense to be autopublished but I see value on being autopopulated.

--
You received this message because you are subscribed to the Google Groups "meteor-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-core...@googlegroups.com.
To post to this group, send email to meteo...@googlegroups.com.
Visit this group at http://groups.google.com/group/meteor-core.
To view this discussion on the web visit https://groups.google.com/d/msgid/meteor-core/48e53850-a213-4f33-9afb-b5be444c20ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chris Cuilla]

I hate special cases too (though realize sometimes that's just the best overall way to do a thing.)

That said, I feel like we need something like profile, but we might actually need a couple of things:

1. Something where the app developer can put user-specific stuff that is not editable by users.

2. Something where users will be able to change stuff.

Obviously these can be handled in separate collections/models with links back to a user. And maybe that's the way to do it. Maybe that's cleaner overall. User remains fairly locked down and if your app needs a user customizable profile object it creates UserProfile collection and links it back to the user ID. Similarly anything that is specific to the user but should only be controlled by the app itself can be a separate collection like UserAppProfile. Alternatively you could use allow/deny to control specific fields within a single object. Either way this eliminates the special case here and makes it more consistent with everything else.

I guess I just talked myself into supporting this deprecation. ;-)

Chris

[Valerio Santinelli]

Hi Sashko,

I feel that a community package that does exactly what the profile is doing now would be much better than keeping the profile as it is in the core of Meteor.

Cheers,

Valerio

[Abigail Watson]

The obvious legitimate use case for user.profile is that of Rapid Prototyping.  It works great, and countless people use it to good effect every day.  The issue at hand isn't necessarily that user.profile is a bug-prone feature, but that there isn't a best-practice for what a secure production-ready deployment should look like.    What's missing is a good refactor path or audit process to take the prototype to a production ready deployment.  Something like a 'secure-profile' package could address this issue nicely.

[Manuel De Leon]

It's very easy for new developers to miss the special case so my 2c is to remove it. You would then have to publish the fields you want explicitly and any operation not allowed is denied. That way you can still do rapid prototyping but be protected when you remove insecure and auto publish.