Matt, The issue here is not a technical one. It is a licensing question.
<IMHO note="I am not a lawyer. Please seak professional advice."> I am going to try to summarize a few page document here. So there will be some details I will try to not comment on. Please read the full document for a better understanding. ARS licensing model does not allow for a "guest" user (undefined to the system) to update data. Unless,maybe, that data is "owned" (field 2) by that user. Or perhaps easier to understand: Remedy does not, in the most strict since, allow for anonymous users to modify anything. And it is generally expected that all interactions with the server would be with a unique login to the end person that the connection is for. So, your "application" would likely be viewed as an attempt to not buy ARS User license and would be a violation of the EULA (End User License Agreement.) The reason any "anonymous" user configuration is even defined for the Web services for ARS is that it is generally considered "ok" to publish (read) data from ARS for free. However a "write token" is required to modify data. With the exception of the "Submitter mode locked", that costs money and must be mapped to a specific person and not "shared" connections. I think your best option is to go down the "Submitter mode locked" model and not map the connection to the client IP but to the persons User ID. Then also allow your application to retrieve the User ID's password (for authentication with ARS) and open a connection for the right user before it does anything with ARS. An issue could still be found if the end user is actually connected to the ARS server (via ARS client) or if your application(web server) is not used in a "sticky session" fashion by the end user too. </IMHO> -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. Never ascribe to malice, that which can be explained by incompetence. On 8/4/06, Matthew Perrault <[EMAIL PROTECTED]> wrote:
Carey, Thanks for the response. However, maybe I wasn't clear, or detailed enough. We have an application that sits on multiple clients around the globe (100,000). You can have several people accessing this application at anytime. For most of them they do not need a login to Remedy. What is happening is they hit this application (and it picks up and uses their IP address). This application then passes information to any number of Web Servers passing along the IP Address. Then a Program on these Web Servers calls our Web Service to Create and Update tickets. When a success response is received, this program sitting on these Web Servers will update the Client So unfortunately your two suggestions are not viable solutions. 1) This application needs to be able to create and update records-->which means a Restricted Read license for the anonymous user is not viable. 2) Creating a login for every web server/application that is going to use this system means that the Anonymous User is no longer functioning due to this. I mean what's the point of having the Anonymous Web Service user on the Mid-Tier configuration tool, if it can only be accessed by one Web Server at a time. Secondly, forcing a login/separate account for every Web Service, from my stand point, violates one of the principal design points of what Web Services are. Also, it forces every one of these Web Applications to pass across the wire the authentication information (I'm sure Security guys will love that). My argument boils down to locking the login by IP Address because it essentially renders Web Services un-useable in a Global application. It is also going to become a greater and greater problem as things move more and more to a wireless architecture: i.e. I'm on my mobile device working my ticket and submit it. I then move from one wireless area to another, and end up picking up a new IP address, and then go back in to modify my ticket. Suddenly I'll get this error. From my stand point a Web Application that calls our Web Service should NEVER get this error. When the Mid-Tier makes the call down to the ARS, the API should be able to identify this as a Web Service call and allow it through as long as the Anonymous user has a Fixed or Floating License. Thanks, Matt -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Carey Matthew Black Sent: Thursday, August 03, 2006 9:24 PM To: [email protected] Subject: Re: Web Service and ARERR 9084 Matthew, Set the AnonUser's license to be a "Read Restricted" license. Or Give each Mid-Tier its own "Anon" user to use. The "one user from one IP address at a time" rule applies at the ARS server API layer. So it does not matter which client is used. (AKA: ARS WebServices are really a WebService wrapped around the ARS API client talking to the ARS server.) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. Never ascribe to malice, that which can be explained by incompetence. On 8/3/06, Matthew Perrault <[EMAIL PROTECTED]> wrote: > All, > > I was wondering if anyone else has experienced this issue: > > Set up 2 Web Servers: X1 and X2 > Set up a Mid Tier Server-6.03 Patch 16: Y > Set up a Remedy Application Server-6.03 Patch 14: Z > Set up a Create Web Service on the remedy side: RemCreate_WebService > Set up an Anonymous User for the Web service: AnonUser > > Build a Consuming application that calls the Web Service yet passes No > authentication info on the two Web Servers. > > Now, if you perform the Call to the Create Remedy Web Service from the > Web Servers at the Same Time, I receive the error: > > ARERR [9084] User is currently connected from another machine. > > So: > X1(RemCreate_WebService)--->Y(AnonUser)--->Z > X2(RemCreate_WebService)--->Y(AnonUser)--->Z > > Now, considering this is a Web Service and NOT the mid-tier client Web > Page, and it is using the Anonymous Authentication, I should NOT be > receiving this error message. Again, this is a Web Service and there is > no client interaction. One would think that I should be able to call a > Web service and consume it from any number of web servers without having > to create a Login for each web server, and without having to give that > anonymous user admin rights. > > Thanks, > Matt > > ________________________________________________________________________ _______ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
