Neil Goodman wrote:
> Thanks. Those suggestions are certainly helpful and I
will try it out
> tonight (thanks for the security tip Moshe). I think
you are right
> that permissions might be the problem.
>
> Does anyone else know what permissions cron is run
under? It would be
> nice if it ran under user 1 permissions, but I don't
think this is the
> case as this same problem is happening when my module
runs under cron.
> Can I use David's method of switching users in cron?
That seems
> counter-intuitive to me because I wouldn't think there
would be a user
> object for me to manipulate.
>
If you run cron.php through a script, or a unix cronjob
(with wget, say)
it's run as the anonymous user. I suspect that if you wanted
to build
security into your hook_cron() you'd have to do it
yourself.
> Neil Goodman
>
> On Feb 5, 2008 9:05 AM, Moshe Weitzman <weitzman tejasa.com
> <mailto:weitzmantejasa.com>> wrote:
>
> This is quite a dangerous operation. If you don't
change back to the
> original uid, whomever calls this page gets to be
uid=1 on the next
> request. There are many reasons why a page might
not complete so you
> have to defend against it. Thanksfully, core now
makes this easy. Just
> add a call to session_save_session(FALSE) before
the user_load().
> After you are done with your save operations, call
> session_save_session(TRUE).
>
> On Feb 5, 2008 9:33 AM, David Metzler
<metzlerdmetzlerd.com
> <mailto:metzlerdmetzlerd.com>>
wrote:
> >
> > Here's an example from my CAS module.
> >
> > // Become user 1 to be able to save
profile information
> > $admin = array('uid'=> 1);
> > $user = user_load($admin);
> >
> > If you're operating as a normal user you'll
want to save away
> the value of
> > the current user, become admin , do your save
stuff, then become
> the normal
> > user again. Something like:
> >
> > global $user;
> > $temp_user = $user;
> > $admin= array('uid' => 1);
> > $user = user_load($admin);
> >
> > ... do some save stuff
> >
> > $user = user_load($temp_user);
> >
> >
> > This of course should only be used when you're
trying to circumvent
> > permissions checked by user_save() (do you
have permissions to
> modify user
> > roles for example).
> >
> > I thought there used to be code in cron.php to
do this, but I
> think I may
> > just be remembering wrong. Perhaps someone
else on the dev list
> could answer
> > the question of who the cron user executes
as.
> >
> > As I said, not 100% sure this is your problem,
but I do know
> you'll have
> > problems having generic users sync up their
roles unless you do this
> > permissions escalation.
> >
> >
> >
> > On Feb 5, 2008, at 5:46 AM, Neil Goodman
wrote:
> > No, how do I go about transitioning to user 1
for the save
> operations?
> >
> > Right now I just call the function and I
assume the permissions
> would be of
> > whoever is using the module at the time. How
do permissions get
> determined
> > with things like hook_cron()?
> >
> > Neil Goodman
> >
> > On Feb 4, 2008 10:44 PM, David Metzler
<metzlerdmetzlerd.com
> <mailto:metzlerdmetzlerd.com>>
wrote:
> > >
> > > Last time I ran into something close to
this it was because of
> > permissions. Are you transitioning to user 1
for the save
> operations?
> > >
> > >
> > > Might be completely off base.... but
that's my experience.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Feb 4, 2008, at 5:34 PM, Neil Goodman
wrote:
> > >
> > > Hello,
> > >
> > > I'm currently trying to solve a bug
report for my module
> > (http://drupal.org/node/
217639). rallycivic keeps getting a
> "__clone method
> > called on non-object" when he runs a
function in my module. My
> module runs
> > through a CiviCRM database and pulls out
certain CiviCRM
> contacts that have
> > membership status. The goal is to get this
status synchronized
> to a Drupal
> > role. There is a static method in the CiviCRM
API called
> > CRM_Core_BAO_UFMatch::getUFId(). This method
will take a CiviCRM
> contact id
> > and return its corresponding Drupal uid. I
then take this list
> of uids and
> > pass it to the user_multiple_role_edit()
function. This function
> uses the
> > user_save() function to apply role changes. I
think that one of
> rallcivic's
> > uids is causing an issue with this function.
From reading the
> user_save()
> > function's code I can see that it tries to
create a new user if
> the uid
> > doesn't exist. For some reason I think it is
trying to do this
> on a valid
> > uid, which throws a duplicate error that
rallycivic has found in
> watchdog:
> > >
> > > "Location
> >
> http://chelmsfordmc.co.uk/admin/settings/ci
vimember_roles/manual_sync
> > > Referrer
> >
> http://chelmsfordmc.co.uk/admin/settings/ci
vimember_roles/manual_sync
> > > Message Duplicate entry '' for key 2
query: INSERT INTO users
> (uid,
> > created, access) VALUES (404, 1202163268,
1202163268) in
> >
/home/chelmsf/public_html/includes/database.mysql.inc on
line 172."
> > >
> > > Then the drupal_clone() function is
called on a bogus object
> and throws
> > the clone method error. At least, that is what
I think is happening.
> > >
> > > Has anyone ran into a situation similar
to this before?
> > >
> > > Neil Goodman
> > >
> > >
> >
> >
> >
>
>
|
