- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-20-2017 02:57 AM
Hi Guys,
I am trying to retrieve the current session's Domain using a server side scoped application script. Using the 'gs.getUser().getDomainID() ' function gives the following error-
'Cannot find function getDomainID in object com.glide.script.fencing.ScopedUser'
Is there any other way to retrieve the current domain using a scoped application script without explicitly calling a globally scoped script?
Any help would be highly appreciated.
Thanks,
Aditya
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-26-2017 11:28 AM
Hi Aditya,
The session/user getDomainID() methods are not exposed to scope currently. As a workaround, I'd suggest creating a Script Include with a method you can call that will create a domain-separated record and just read the domain off of it. Like this:
var DomainInfo = Class.create();
DomainInfo.prototype = {
initialize: function() {
},
getCurrentDomain : function() {
var throwAwayRecord = new GlideRecord("sys_user");
throwAwayRecord.newRecord();
return throwAwayRecord.getValue("sys_domain");
},
type: 'DomainInfo'
};
Then when you want to get the domain, you call your Script Include:
var currentDomain = new DomainInfo().getCurrentDomain();
This assumes that the sys_user table is domain-separated. I'd suggest using a domain-separated table which doesn't have Number Maintenance or other auto-incrementing stuff, since we are deliberately initializing a full record, but never saving it.
Thanks,
Cory Seering
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2017 12:55 AM
Hi Alex,
Did you find anything about this? I have been stuck on this for hours, and still haven't found anything.
Thanks,
Aditya
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2017 01:16 AM
Hi Aditya,
Seems like you cannot use getDomainID() in a scoped application, so we'll have to find a workaround. I never worked with domain separation myself, but can't you just dot-walk to the domain field in the sys_user table? And use that field to conclude in which domain they are in?
Alex
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2017 02:17 AM
Hi Alex,
Dot walking will just return the user's domain from the user table.
However, I am trying to build queries in my application script using the current session's domain which may be different from the user's domain.
Maybe we can provide access to these functions using the cross scope privilege application.
Just don't know what API name to use in the 'Target Name Field'.
Thanks,
Aditya
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2017 03:17 AM
Hello Adithya,
Here you can find,
Cross-scope privilege record:
Runtime access tracking uses cross-scope privilege records to determine which script operations and targets the system allows to run.
- Runtime access tracking is set to Tracking or Enforcing.
- A script attempts to access another application.
Each cross-scope privilege record contains the following information.
Field | Description |
---|---|
Source Scope | The application requesting runtime access to another application's resources. |
Target Scope | The application whose resources are being requested. |
Target Name | The name of the table, script include, or script object being requested. |
Target Type | The type of request: table, script include, or script object. |
Operation | The operation the script performs on the target. The target type determines the available operations. Tables support the read, write, create, and delete operations. Script includes and script objects only support the execute API operation. |
Status | The authorization for this record: requested, allowed, or denied |
Administrators can manually create cross-scope privilege records for application developers in advance to communicate which cross-scope resources they expect developers to access. For example, administrators could create these cross-scope privilege records to permit application developers access to resources from Incident Management.
Source Scope | Target Scope | Target Name | Operation | Status |
---|---|---|---|---|
My App | Global | incident | Read | Allowed |
My App | Global | incident | Write | Allowed |
My App | Global | ScopedGlideRecord | Execute API | Allowed |
During testing, application developers should run all of their application scripting logic to ensure the system creates any necessary cross-scope privilege records. After application publication, the system only allows runtime requests to run that have a valid cross-scope privilege record.
Thanks,
Rajashekhar Mushke
Rising star : 2022 - 2024
Community Leader -2018
Connect me on LinkedIn : Rajashekhar Mushke
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2017 06:55 AM
Hello Aditya Mishra,
If your query is Resolved would you mind marking the Answer as correct and close the thread or if there is any query on the same let me know,
This enables other customers to learn from your thread.
Thank you in advance.
If you are viewing this from the community inbox you will not see the correct answer button. If so, please review How to Mark Answers Correct From Inbox View.
Thanks,
Rajashekhar Mushke
Rising star : 2022 - 2024
Community Leader -2018
Connect me on LinkedIn : Rajashekhar Mushke