Hi Henry,

This is the line that results in a null value:

<code>
return (Thread.CurrentPrincipal as AppPrincipal);
</code>

As far as my application is concerned, it has the right connection string and all other aspects of iBO work as expected. It is when I process payment, iBO tries to log pci event (Which it never used to before), which then results in that error. a WCF webservice is stateless. It has no concept of who the current logged in user is. It is only aware of the user context that IIS or the IIS apppool is running in.

The log pci event inserts a log entry in the database about the credit card payment being made. It tries to figure out who the user is that is trying to make the payment and when the above code is called, it results in  a null value.

Regardless, when an API results in an object reference not set to an instance of an object, it has to be a bug even if it means a try catch block should be implemented.

Nasser

... it could fail a little more gracefully, but the code is assuming the standard iBO initialization routine of iboAdmin.InitializeSystem, followed by CStaffUser.Login (or CContactUser.Login).  You should be able to resolve the problem by calling one of the login methods after you call InitializeSystem. 

I am calling iboAdmin.InitializeSystem().

I am also calling CContactUser.LoginByWebLogin("manager", "manager");

Henry, I presume you have used iBO's before? Do you realise that I cannot even instantiate a gift object without passing an IiMISUser object.

Again, all other ibo calls are working as expected, for example: CContact contact = new CContact(user, "91045"); works as expected.

Any other thoughts apart from initialization or login or ibo usage issues?

Nasser

LoginByWebLogin ("manager") instead of LoginByWebLogin("manager", "manager").  It looks like there may be a bug in LoginByWebLogin(login, password), where the app principal isn't set properly.

...of LoginByWebLogin resolve the problem?

It appears it is sufficent just to call:
contactUser = Asi.iBO.ContactManagement.CContactUser.LoginByWebLogin(staffLoginUserId);
To get the App Principal Setup.  I call the above code, and then do what I was doing before, using a staff user.  I never end up user the contactUser in the code again.
This seems to resolve that particular issue.

Before I was just doing:
staffUser = CStaffUser.Login(staffLoginUserId, staffLoginPW);
And using staffUser everywhere

Now I do:
staffUser = CStaffUser.Login(staffLoginUserId, staffLoginPW);
contactUser = Asi.iBO.ContactManagement.CContactUser.LoginByWebLogin(staffLoginUserId);

And continue to use staffUser like before.  I don't use contactUser in my code after creating it.  But everything works.

Jason

Yes, LoginByWeblogin("manager") works.

Shouldn't the other method that accepts the password be deprecated or removed, so we instantly get a compile time error instead of "Object reference...",
then spend half an hour trying to reflect the code to see what the problem is,
then try and convince someone on iMIS community that it is indeed a bug.

Some way of informing the wider community where iBO based implementations are increasing on a daily rate would be highly appreciated.

So now you can use iBO to login as manager without knowing the password. A bug or a feature. Fascinating!

Nasser

It's a feature, so that system-level code can run without having to store a password (insecurely) anywhere. It's not a security hole because in order to run that code, someone either has to have access to add the code to your website or otherwise know the connection string to your database, at which point they can do anything they want anyway.

The overload with the password exists so that code can use iBO.NET to validate user logins. Both overloads are needed, they just are intended for different usage scenarios.

Eric Means
System Architect, ASI

I'm trying to use ChangeWebLogin to assign a username to a contact who doesn't already have one.  I can only find overloads for:

ChangeWebLogin(username, password)
ChangeWebLogin(username, authorizedUserWebLogin, authorizedUserWebPassword)

Since the person doesn't yet have a username, I rather doubt they have a password, so I don't expect the first variation to work.

The second flavor requires knowing a username and password.  I'd really like to avoid embedding a username and password in my app.

Is there a way to use the LoginByWebLogin() method so that I can assign a new username?

--
Bruce Wilson
Director, Technical Services
RSM McGladrey, Inc.

Er, got a little mixed up there.  Let me start over.

ChangePassword has two overloads:

ChangePassword(password, newpassword)
ChangePassword(newpassword, authorizedWebUserLogin, authorizedUserPassword)

The contact I'm trying to activate has no username or password, so I don't think I can use the first form.  I can't use the second form without knowing an authorized username and their plaintext password.

I'm calling ChangePassword first, because ChangeWebLogin only has one form, which requires I know the password of the user I'm changing.

How can I assign both the username and password for a contact who doesn't have either without knowing the plaintext password of a user?

--
Bruce Wilson
Director, Technical Services
RSM McGladrey, Inc.