errorCode 25 with LOGINUSER web service when not in Default org

Nick Tierney shared this problem 7 years ago
Resolved

When sending a web service request from a user that doesn't have access to the default organization, I receive error 25 when trying to do any kind of request (LOGINUSER, ADDUSER...)


The user role has access to web services and all administration and user administration options. When adding them to the default org in addition to their own org, the request works successfully.


YF Version 7.1


Request

  1. <soapenv:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ser="http://service.web.mi.hof.com" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
  2. <soapenv:Header/>
  3. <soapenv:Body>
  4. <ser:remoteAdministrationCall soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  5. <in0 xsi:type="ser:AdministrationServiceRequest">
  6. <function xsi:type="xsd:string">LOGINUSER</function>
  7. <loginId xsi:type="xsd:string">*****</loginId>
  8. <password xsi:type="xsd:string">*****</password>
  9. <orgId xsi:type="xsd:int">1</orgId>
  10. <orgRef xsi:type="xsd:string">orgA</orgRef>
  11. </in0>
  12. </ser:remoteAdministrationCall>
  13. </soapenv:Body>
  14. </soapenv:Envelope>

Replies (10)

photo
1

Hi Nick,


I tested this out over here and had the same findings as yourself, so I researched it with the devs and they said the user sending the request probably shouldn't really need to be a member of the default org as well as the client org and they can look into it if need be. However, having said that, there is no extra functionality to be gained from only being a member of one client org, or in other words, we can't see any disadvantages to doing the simple workaround of making sure the web service administrator (if I may call the user that) is a member of the default org as well as the client org, but if there is an important disadvantage that we haven't thought of then please let us know.


regards,

David

photo
1

Thanks for the quick reply David!


I can currently see one important disadvantage, I'm hoping you can tell me I'm doing something wrong here.

Currently only if you are in th default org can you manage client organizations. I would like these org admins to be able to do anything but manage organizations, but as soon as I give them the ability to manage roles they can just give themselves the ability to edit orgs, log into the default org, then add them self to all of the other ones that they currently don't have access to. If thy aren't a member of the default org here then they couldn't edit orgs.


Let me know what you think,

Nick

photo
1

Hi Nick,


If I have understood you correctly then I think I have a solution for you...you see there is a feature called Restrict Visible Roles which allows you to hide certain roles from "sub-Admins". Unfortunately I can't seem to find a wiki page about it, however, there is the following useful forum page on it that describes what it does and how to configure it:


http://www.yellowfinbi.com/YFForum-Can-I-create-a-super-user-Admin-?thread=124255


Please have a read and then a play with it and let us know what you think.


regards,

David

photo
1

When I tried doing this I ran into 2 problems: the docs are for 6.1 and I didn't see any menu to limit the visible roles in 7.1


Once a user can modify roles, they can just modify them self to toggle off the setting to restrict roles

photo
1

To clarify I could modify the role to restrict modify roles but the menu for administration configuration didn't have a list of roles to restrict the user to

photo
1

The only way I can see this working is having one admin with the ability to create roles and manage organizations, and then a second admin in the default org that can administrate everything else but that. It's not optimal since I'd like the second admin to be able to create roles only in his own org without help from the other admin, but I don't think there's a way around it seeing as the role administrator in a default org gives permissions to basically anything.

photo
1

Hi Nick,


OK, I can see that it doesn't fit exactly with what you had in mind, so what I've done is to raise a defect (247330) for this to be fixed such that a client org admin doesn't have to also be a member of the Default Org in order to send web service calls. I hope the devs don't tell me it's an enhancement rather than a defect, but I really don't think it is and in any case I'm pretty sure it will just be a matter of adjusting one line of code. I don't have an ETA at the moment for the fix but it's certainlyi too late to make it in the Dec build, so it will be Jan or Feb. I hope that's OK with you.


regards,

David

photo
1

Hi Dave, any update on this?

photo
photo
1

Thanks so much for the help sounds good to me, we'll see how this pans out!

photo
1

Hi Nick,

We're currently looking at webservice calls as we're prepping for the new mobile app, and came across this older item which was left inactioned. Apologies as it slipped through the cracks, which is not the norm.


After discussing this in detail with devs it seems we initially thought this was a defect, but after more thought realized it's not a good idea to allow a user to run admin calls when they're not part of the default org.

Please let me know if you have any questions or concerns on this.

Regards,

Mike

photo
1

Hi Nick,

I'm going to go ahead and mark this one as Resolved since I haven't heard back from you, and this has been confirmed as non-defective behavior, but if you have further questions or concerns on this, if you respond, it will re-open the case and put it back in my queue and I'll be happy to help.

Regards,

Mike

Leave a Comment
 
Attach a file