By beetleskin on

Hi there,

I have a Drupal 7 installation which has to display user-specific content. However, my users and their profile data are stored within another backend server I communicate with via SOAP. I don't want to save users and their profiles in the Drupal db, but use the benefits of Drupals user module. Thats the stuff.

I read a bit about the user modules helpfer functions ( user_external_load, (user_external_login_register, authmaps) but it occures to me that first of all, all those functions create a local persistence of the externally loaded user and secondly do not deal with the users external profile data. So I wont achieve my goal by using this helper functions..., will I?

So I came up with a few compromises:

  • use a single shadow user which is registered in drupal. match the customers login-data with the webservice. store profile-relevant information temporarly in the $_SESSION variable.

    • pro: simple implementation
    con: I cant use the user module (profile handling, user_load and all the cool stuff)

  • match the customers login-data with the webservice. get users profile informations from webservice. store (user_save()) the user locally. delete the saved user at session ending.

    • pro: I can use the user module
    con: persistence! traffic between Drupal and backend

  • override user_load() and user_authenticate. both functions call the external backend.

    • pro: I can use the user module
    con: Drupal core hacking :/ and a lot of "senseless" traffic

  • override user_load() and user_authenticate. the users data is, after successful login, stored in the $_SESSION variable. every call to user_load() reads the session variable.

    • pro: I can use the user module
    con: Drupal core hacking :/

    Well... what do you think of that solutions, has anyone heard of similar problems and implementations?

    Thanks

    ps. I dont hava direct access to the backends database, as far as I understand authmaps, they wont help as well...?

    ⋅ Categories: Drupal 7.x

    Comments

    beetleskin’s picture

    beetleskin commented

    [givin it a slightly push]

    adub’s picture

    adub commented

    The usual pattern I've seen in d6 is to persist the user and profile locally and not try to bypass the user system (giving you security as much as functionality). Typically, you would pull down any changes to the user and profile from the external system on login, and push out any local changes on update/insert. (You could pull down on page load but the performance would be pretty horrible.)

    What I'm wondering is whether in d7 it's possible to extend the entity fields (or even repurpose stream wrappers for external field storage). Might also be worth looking at how external data sources are handled in views 3. (Caching would likely be a major factor as well.)