Multiple/Dynamic Login Information

[tfr...@gmail.com]

Is there a way to dynamically change the username/password information
that transfer sends to the back-end database?

We'd like to be able to have a user log into our system, and once
authenticated, call a method on transfer to assign the username/
password that transfer users when doing CRUD on the back end db.


Is this possible? If not, how soon will something like this be
available?

[Peter Bell]

Would each user be logged into a different database? Would the login
be performed against a database (and if so, how)? What would happen if
multiple people entered different usernames and passwords within the
life of an application? (Not saying there aren't answers, but the
answers may affect the ideal solution).

Remember that transfer reads in an XML file and ColdFusion makes it
easy to generate XML and/or performing operations on text files.

I'd look at saving an xml file with special strings for the username
and password. You could then write some code that a successful login
would fire off that would pass the username and password provided into
a method that would load up the XML file and then either operate on it
using XML or just perform a simple RegEx to change the username and
password. Save it to the location transfer looks for its XML and then
load up transfer into (presumably) the application scope.

All kind of potential issues you'll have to think for but it isn't an
insoluble problem.

I personally would vote against it being added to transfer unless I
saw an outpouring of other people who have the exact same requirement.
Seems like a bit of an unusual case to me, but maybe I don't get out
enough :->

Good luck with the system.

Best Wishes,
Peter

[tfr...@gmail.com]

Thanks for the prompt reply and information.

The reason I am going down this path is for logging purposes. We have
a database with 3-4 tables that have a lot of fields, and we'd like to
be able to track changes to individual fields, etc. We have software
available that would do all of this for us based on triggers, but it
requires each user connects to the database using a distinct account.
From there it will keep track of who made changes, when they did it,
what fields they changed, the before/after values, etc.

The downside to this is we have to maintain the usernames/passwords in
our system as well as our DB as you mention, but the benefits of going
this route (not having to write a complex logging application) far
outweigh keeping the logins in sync.

I have already modified the transfer factory to parse a custom XML
file that I build on the fly, but having to do this on every request
seems like a lot of overhead. Is there any way to do this in memory
instead of on disk? Can we make transfer live in the session scope,
and set the username/password a single time? Or does it have to go to
disk on every request?

On May 6, 1:58 pm, Peter Bell <pb...@systemsforge.com> wrote:
> Would each user be logged into a different database? Would the login
> be performed against a database (and if so, how)? What would happen if
> multiple people entered different usernames and passwords within the
> life of an application? (Not saying there aren't answers, but the
> answers may affect the ideal solution).
>
> Remember that transfer reads in an XML file and ColdFusion makes it
> easy to generate XML and/or performing operations on text files.
>
> I'd look at saving an xml file with special strings for the username
> and password. You could then write some code that a successful login
> would fire off that would pass the username and password provided into
> a method that would load up the XML file and then either operate on it
> using XML or just perform a simple RegEx to change the username and
> password. Save it to the location transfer looks for its XML and then
> load up transfer into (presumably) the application scope.
>
> All kind of potential issues you'll have to think for but it isn't an
> insoluble problem.
>
> I personally would vote against it being added to transfer unless I
> saw an outpouring of other people who have the exact same requirement.
> Seems like a bit of an unusual case to me, but maybe I don't get out
> enough :->
>
> Good luck with the system.
>
> Best Wishes,
> Peter
>

[Brian Kotek]

This is an odd situation (you have to create individual logins for everyone who uses the app?) but yes, you could create an instance of Transfer for each session using its own DSN information and store it in the session scope.

[Peter Bell]

Maybe Mark would have something smart to say about this, but doesn't
sound like a great use case for an ORM. You could theoretically have
transfer in the session scope for each user and have all caching set
to off, but I don't know the overhead that'd add to the app in terms
of session loading or server memory requirements. I also have no idea
if the different instances of transfer would step over each other when
talking to the db - I mean, it may not be a problem at all, but I'm
guessing not very many people are running hundreds of session based
instances of transfer on a given machine so I doubt it'd be tested or
supported.

The usual way to do this is to roll the logging in your application.
If you want to connect every user with their own username and
password, I just have a feeling you're going to end up in a world of
hurt all the way up and down the stack, but I've been wrong plenty of
times before, so who knows . . .

Best Wishes,
Peter

[Peter Bell]

I'd also think about database connection pooling and things like that. I think you're going to have to either be using connection strings or separate DSN's per user (may be wrong - not something I ever looked into). I'd think carefully about the approach and maybe hack up a proof of concept that you could run some simple load testing against before committing to the architecture. 

If you do go this way, please report on your experiences - would love to learn if it worked out.

Best Wishes,

Peter

[Brian Kotek]

Just a note that he could leave caching on and set it to instance, so that each instance in the session scope would maintain its own cache.

[Peter Bell]

What happens if I make a change as user 1 that affects data that user 2 wants to look at (assuming the data sets a given user can edit and any other user can view aren't guaranteed to be disjoint sets). Would it be smart enough to update the caches across all instances?

[Daemach]

The username and password attributes in the CFQuery tag are meant
specifically to bypass the DSN username and password on a query by
query basis.

http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=Tags_p-q_17.html#1102316

I don't think the need for security negates the use case for ORM.

On May 6, 2:30 pm, Peter Bell <pb...@systemsforge.com> wrote:
> Maybe Mark would have something smart to say about this, but doesn't
> sound like a great use case for an ORM. You could theoretically have
> transfer in the session scope for each user and have all caching set
> to off, but I don't know the overhead that'd add to the app in terms
> of session loading or server memory requirements. I also have no idea
> if the different instances of transfer would step over each other when
> talking to the db - I mean, it may not be a problem at all, but I'm
> guessing not very many people are running hundreds of session based
> instances of transfer on a given machine so I doubt it'd be tested or
> supported.
>
> The usual way to do this is to roll the logging in your application.
> If you want to connect every user with their own username and
> password, I just have a feeling you're going to end up in a world of
> hurt all the way up and down the stack, but I've been wrong plenty of
> times before, so who knows . . .
>
> Best Wishes,
> Peter
>

[Brian Kotek]

Ah very true, I highly doubt that it would synchronize across the instances. So if that is an issue then caching would indeed have to be disabled, at least for any editable tables.

[Brian Kotek]

The fact that every session would have its own instance, coupled with the fact that caching would need to be disabled, probably means that the poster will need to very carefully consider whether Transfer is going to be an appropriate fit.

[Paul Marcotte]

On the other hand, the cache could be set to server so that all session instances would share the server stored cache.

Paul

--
Paul Marcotte
Fancy Bread - in the heart or in the head?
http://www.fancybread.com

[Brian Kotek]

Hmm, very true Paul! That would make Transfer more useful as an option, since the cache speeds things up greatly.

[Peter Bell]

If it did so would it still correctly assign all of the write operations to the correct user?

[Peter Bell]

That's good re: DSN - just something I've never needed to use.

Never suggested that security negates the use case for ORM. However,
your implementation of security is very unusual for an application
(not wrong, but not terribly common in my experience) and it may or
may not play well with the way that a given ORM thinks/works as your
use case was probably not taken into account when building the ORM and
if you did run into issues I think it's unlikely the ORM would be
changed to support your use case unless it's much more popular than I
realize or the change was extremely minor and didn't inconvenience
most of the rest of the user base.

Best Wishes,
Peter

[Brian Kotek]

I beleive so. Each session-specific instance of Transfer would have its own datasource configuration so each one should use the correct username and password.

[Mark Mandel]

Just coming into this, forgot to reply -

You * could * set the cache to application scope / server scope, and
that would solve that issue.

But that being said, storing an instance of Transfer inside the
session scope for every user would probably be a pretty huge memory
hog. I'd be a bit worried about it, to tell you the truth.

I'm not sure how good a fit this is going to be in this scenario, but
I'm happy to hear how you go along with it.

Mark

--
E: mark....@gmail.com
W: www.compoundtheory.com