Re: ticket direct URLs and login sessions

2013-02-26 Thread Brittain, Mark 
HI Ron,

Just learning this myself. With the ITSM Notification Engine, an OTB 
notification when the Incident is assigned to a person, creates a record in the 
NTE:Notifier form and the engine send out the email. It appears that when you 
select the URL, it take you to the NTE:Notifier record and then workflow 
redirects you to the Incident, change, etc.

The ITSM Notification Engine Guide explains this better than I am doing here. 
Also OTB, 21 days after the notification is sent, the NTE:Notifier record is 
archive/deleted and the URL is no longer valid.

Mark

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron
Sent: Tuesday, February 26, 2013 12:49 PM
To: arslist@ARSLIST.ORG
Subject: ticket direct URLs and login sessions

**
Hello,

We recently updated our notification templates to contain HTML direct links to 
incidents and changes. We disabled the default link at the beginning of all 
messages and created our own. An example of our INC URL is this:

http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Desk&server=AR_SERVER&qual='Incident
 ID*%2B'%3D%22INC_NUMBER%22

This is the odd behavior and it happens in all browsers.


· If a user is not logged into the mid-tier, the link requires 
authentication and then they're taken directly to the Incident. Normal and as 
expected.

· If the user (not already logged into the mid-tier) uses the direct 
link, logs in, accesses the ticket AND THEN (without logging out) clicks on 
another direct link from a different email notification (or the same), they are 
taken directly to that ticket without any required authentication. Normal and 
as expected.

· If the user had already been logged into the mid-tier, the direct 
link in the notification still requires authentication instead of taking them 
directly in. Odd

o   If the user declines the authentication (closes the browser tab/window) and 
goes back to their original, already logged in session, that session has now 
been logged out and they have to re-authenticate (Session is invalid or has 
timed out. Please reload page to log in again. (ARERR 9201)). Annoying

Now, I've done some more testing. I re-enabled the 'Add URL' on the 
notification filter that has the form of:

http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifier&server=AR_SERVER&eid=NTS00772848
 (<-- I don't know what the NTS number relates to)

The new notifications (in Dev) have both URL types. With this being the case, I 
can't make it fail as before. I've also re-removed the 'Add URL' from the 
filter and it still won't fail in that environment though our production 
environment is still acting odd.

This feels like something has gotten cached that works for the filter URL but 
not for my direct one. Anyone have any idea what's going on here?

Thanks again,
Ron
_ARSlist: "Where the Answers Are" and have been for 20 years_


This e-mail is the property of NaviSite, Inc. It is intended only for the 
person or entity to which it is addressed and may contain information that is 
privileged, confidential, or otherwise protected from disclosure. Distribution 
or copying of this e-mail, or the information contained herein, to anyone other 
than the intended recipient is prohibited.

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ticket direct URLs and login sessions

2013-02-26 Thread Peters, Ron 
Excellent. That makes sense. The 21 day expiration also makes sense with when 
those links stopped working. Now to figure out the authentication oddity.

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Brittain, Mark
Sent: Tuesday, February 26, 2013 10:06 AM
To: arslist@ARSLIST.ORG
Subject: Re: ticket direct URLs and login sessions

**
HI Ron,

Just learning this myself. With the ITSM Notification Engine, an OTB 
notification when the Incident is assigned to a person, creates a record in the 
NTE:Notifier form and the engine send out the email. It appears that when you 
select the URL, it take you to the NTE:Notifier record and then workflow 
redirects you to the Incident, change, etc.

The ITSM Notification Engine Guide explains this better than I am doing here. 
Also OTB, 21 days after the notification is sent, the NTE:Notifier record is 
archive/deleted and the URL is no longer valid.

Mark

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron
Sent: Tuesday, February 26, 2013 12:49 PM
To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>
Subject: ticket direct URLs and login sessions

**
Hello,

We recently updated our notification templates to contain HTML direct links to 
incidents and changes. We disabled the default link at the beginning of all 
messages and created our own. An example of our INC URL is this:

http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Desk&server=AR_SERVER&qual='Incident
 ID*%2B'%3D%22INC_NUMBER%22

This is the odd behavior and it happens in all browsers.


· If a user is not logged into the mid-tier, the link requires 
authentication and then they're taken directly to the Incident. Normal and as 
expected.

· If the user (not already logged into the mid-tier) uses the direct 
link, logs in, accesses the ticket AND THEN (without logging out) clicks on 
another direct link from a different email notification (or the same), they are 
taken directly to that ticket without any required authentication. Normal and 
as expected.

· If the user had already been logged into the mid-tier, the direct 
link in the notification still requires authentication instead of taking them 
directly in. Odd

o   If the user declines the authentication (closes the browser tab/window) and 
goes back to their original, already logged in session, that session has now 
been logged out and they have to re-authenticate (Session is invalid or has 
timed out. Please reload page to log in again. (ARERR 9201)). Annoying

Now, I've done some more testing. I re-enabled the 'Add URL' on the 
notification filter that has the form of:

http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifier&server=AR_SERVER&eid=NTS00772848<http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=NTE%3aNotifier&server=AR_SERVER&eid=NTS00772848>
 (<-- I don't know what the NTS number relates to)

The new notifications (in Dev) have both URL types. With this being the case, I 
can't make it fail as before. I've also re-removed the 'Add URL' from the 
filter and it still won't fail in that environment though our production 
environment is still acting odd.

This feels like something has gotten cached that works for the filter URL but 
not for my direct one. Anyone have any idea what's going on here?

Thanks again,
Ron
_ARSlist: "Where the Answers Are" and have been for 20 years_


This e-mail is the property of NaviSite, Inc. It is intended only for the 
person or entity to which it is addressed and may contain information that is 
privileged, confidential, or otherwise protected from disclosure. Distribution 
or copying of this e-mail, or the information contained herein, to anyone other 
than the intended recipient is prohibited.
_ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ticket direct URLs and login sessions

2013-02-26 Thread Longwing, LJ CTR MDA/IC 
Ron,
I don't have an answer for the question...but I can tell you what the NTS 
number is :)

That is a control form that all notifications are sent out through, and there 
is workflow on it that opens the proper form that needs to be opened for that 
notification.

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron
Sent: Tuesday, February 26, 2013 10:49 AM
To: arslist@ARSLIST.ORG
Subject: ticket direct URLs and login sessions

**
Hello,

We recently updated our notification templates to contain HTML direct links to 
incidents and changes. We disabled the default link at the beginning of all 
messages and created our own. An example of our INC URL is this:

http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Desk&server=AR_SERVER&qual='Incident
 ID*%2B'%3D%22INC_NUMBER%22

This is the odd behavior and it happens in all browsers.


· If a user is not logged into the mid-tier, the link requires 
authentication and then they're taken directly to the Incident. Normal and as 
expected.

· If the user (not already logged into the mid-tier) uses the direct 
link, logs in, accesses the ticket AND THEN (without logging out) clicks on 
another direct link from a different email notification (or the same), they are 
taken directly to that ticket without any required authentication. Normal and 
as expected.

· If the user had already been logged into the mid-tier, the direct 
link in the notification still requires authentication instead of taking them 
directly in. Odd

o   If the user declines the authentication (closes the browser tab/window) and 
goes back to their original, already logged in session, that session has now 
been logged out and they have to re-authenticate (Session is invalid or has 
timed out. Please reload page to log in again. (ARERR 9201)). Annoying

Now, I've done some more testing. I re-enabled the 'Add URL' on the 
notification filter that has the form of:

http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifier&server=AR_SERVER&eid=NTS00772848
 (<-- I don't know what the NTS number relates to)

The new notifications (in Dev) have both URL types. With this being the case, I 
can't make it fail as before. I've also re-removed the 'Add URL' from the 
filter and it still won't fail in that environment though our production 
environment is still acting odd.

This feels like something has gotten cached that works for the filter URL but 
not for my direct one. Anyone have any idea what's going on here?

Thanks again,
Ron
_ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ticket direct URLs and login sessions

2013-02-26 Thread David Durling 
Ron,

One url lists "...arsys//servlet..." (two slashes) and the other 
"...arsys/servlet..".  Is that a typo, or might it have something to do with 
the authentication issue?

David Durling
University of Georgia


From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, LJ CTR MDA/IC
Sent: Tuesday, February 26, 2013 2:09 PM
To: arslist@ARSLIST.ORG
Subject: Re: ticket direct URLs and login sessions

**
Ron,
I don't have an answer for the question...but I can tell you what the NTS 
number is :)

That is a control form that all notifications are sent out through, and there 
is workflow on it that opens the proper form that needs to be opened for that 
notification.

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron
Sent: Tuesday, February 26, 2013 10:49 AM
To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>
Subject: ticket direct URLs and login sessions

**
Hello,

We recently updated our notification templates to contain HTML direct links to 
incidents and changes. We disabled the default link at the beginning of all 
messages and created our own. An example of our INC URL is this:

http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Desk&server=AR_SERVER&qual='Incident
 ID*%2B'%3D%22INC_NUMBER%22

This is the odd behavior and it happens in all browsers.


* If a user is not logged into the mid-tier, the link requires 
authentication and then they're taken directly to the Incident. Normal and as 
expected.

* If the user (not already logged into the mid-tier) uses the direct 
link, logs in, accesses the ticket AND THEN (without logging out) clicks on 
another direct link from a different email notification (or the same), they are 
taken directly to that ticket without any required authentication. Normal and 
as expected.

* If the user had already been logged into the mid-tier, the direct 
link in the notification still requires authentication instead of taking them 
directly in. Odd

o   If the user declines the authentication (closes the browser tab/window) and 
goes back to their original, already logged in session, that session has now 
been logged out and they have to re-authenticate (Session is invalid or has 
timed out. Please reload page to log in again. (ARERR 9201)). Annoying

Now, I've done some more testing. I re-enabled the 'Add URL' on the 
notification filter that has the form of:

http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifier&server=AR_SERVER&eid=NTS00772848<http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=NTE%3aNotifier&server=AR_SERVER&eid=NTS00772848>
 (<-- I don't know what the NTS number relates to)

The new notifications (in Dev) have both URL types. With this being the case, I 
can't make it fail as before. I've also re-removed the 'Add URL' from the 
filter and it still won't fail in that environment though our production 
environment is still acting odd.

This feels like something has gotten cached that works for the filter URL but 
not for my direct one. Anyone have any idea what's going on here?

Thanks again,
Ron
_ARSlist: "Where the Answers Are" and have been for 20 years_
_ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ticket direct URLs and login sessions

2013-02-26 Thread Peters, Ron 
I did notice that difference and it is not a typo. It comes from the OOTB link 
from the filter notification. I'll give it a shot to see if it makes any 
difference. Not sure why this seems like so much black magic.

Thanks,
Ron

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of David Durling
Sent: Tuesday, February 26, 2013 11:26 AM
To: arslist@ARSLIST.ORG
Subject: Re: ticket direct URLs and login sessions

**
Ron,

One url lists "...arsys//servlet..." (two slashes) and the other 
"...arsys/servlet..".  Is that a typo, or might it have something to do with 
the authentication issue?

David Durling
University of Georgia


From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, LJ CTR MDA/IC
Sent: Tuesday, February 26, 2013 2:09 PM
To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>
Subject: Re: ticket direct URLs and login sessions

**
Ron,
I don't have an answer for the question...but I can tell you what the NTS 
number is :)

That is a control form that all notifications are sent out through, and there 
is workflow on it that opens the proper form that needs to be opened for that 
notification.

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron
Sent: Tuesday, February 26, 2013 10:49 AM
To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>
Subject: ticket direct URLs and login sessions

**
Hello,

We recently updated our notification templates to contain HTML direct links to 
incidents and changes. We disabled the default link at the beginning of all 
messages and created our own. An example of our INC URL is this:

http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Desk&server=AR_SERVER&qual='Incident
 ID*%2B'%3D%22INC_NUMBER%22

This is the odd behavior and it happens in all browsers.


· If a user is not logged into the mid-tier, the link requires 
authentication and then they're taken directly to the Incident. Normal and as 
expected.

· If the user (not already logged into the mid-tier) uses the direct 
link, logs in, accesses the ticket AND THEN (without logging out) clicks on 
another direct link from a different email notification (or the same), they are 
taken directly to that ticket without any required authentication. Normal and 
as expected.

· If the user had already been logged into the mid-tier, the direct 
link in the notification still requires authentication instead of taking them 
directly in. Odd

o   If the user declines the authentication (closes the browser tab/window) and 
goes back to their original, already logged in session, that session has now 
been logged out and they have to re-authenticate (Session is invalid or has 
timed out. Please reload page to log in again. (ARERR 9201)). Annoying

Now, I've done some more testing. I re-enabled the 'Add URL' on the 
notification filter that has the form of:

http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifier&server=AR_SERVER&eid=NTS00772848<http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=NTE%3aNotifier&server=AR_SERVER&eid=NTS00772848>
 (<-- I don't know what the NTS number relates to)

The new notifications (in Dev) have both URL types. With this being the case, I 
can't make it fail as before. I've also re-removed the 'Add URL' from the 
filter and it still won't fail in that environment though our production 
environment is still acting odd.

This feels like something has gotten cached that works for the filter URL but 
not for my direct one. Anyone have any idea what's going on here?

Thanks again,
Ron
_ARSlist: "Where the Answers Are" and have been for 20 years_
_ARSlist: "Where the Answers Are" and have been for 20 years_
_ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ticket direct URLs and login sessions

2013-02-26 Thread Peters, Ron 
Thanks for the info.

Ron

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Longwing, LJ CTR MDA/IC
Sent: Tuesday, February 26, 2013 11:09 AM
To: arslist@ARSLIST.ORG
Subject: Re: ticket direct URLs and login sessions

**
Ron,
I don't have an answer for the question...but I can tell you what the NTS 
number is :)

That is a control form that all notifications are sent out through, and there 
is workflow on it that opens the proper form that needs to be opened for that 
notification.

From: Action Request System discussion list(ARSList) 
[mailto:arslist@ARSLIST.ORG] On Behalf Of Peters, Ron
Sent: Tuesday, February 26, 2013 10:49 AM
To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>
Subject: ticket direct URLs and login sessions

**
Hello,

We recently updated our notification templates to contain HTML direct links to 
incidents and changes. We disabled the default link at the beginning of all 
messages and created our own. An example of our INC URL is this:

http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Desk&server=AR_SERVER&qual='Incident
 ID*%2B'%3D%22INC_NUMBER%22

This is the odd behavior and it happens in all browsers.


· If a user is not logged into the mid-tier, the link requires 
authentication and then they're taken directly to the Incident. Normal and as 
expected.

· If the user (not already logged into the mid-tier) uses the direct 
link, logs in, accesses the ticket AND THEN (without logging out) clicks on 
another direct link from a different email notification (or the same), they are 
taken directly to that ticket without any required authentication. Normal and 
as expected.

· If the user had already been logged into the mid-tier, the direct 
link in the notification still requires authentication instead of taking them 
directly in. Odd

o   If the user declines the authentication (closes the browser tab/window) and 
goes back to their original, already logged in session, that session has now 
been logged out and they have to re-authenticate (Session is invalid or has 
timed out. Please reload page to log in again. (ARERR 9201)). Annoying

Now, I've done some more testing. I re-enabled the 'Add URL' on the 
notification filter that has the form of:

http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifier&server=AR_SERVER&eid=NTS00772848<http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=NTE%3aNotifier&server=AR_SERVER&eid=NTS00772848>
 (<-- I don't know what the NTS number relates to)

The new notifications (in Dev) have both URL types. With this being the case, I 
can't make it fail as before. I've also re-removed the 'Add URL' from the 
filter and it still won't fail in that environment though our production 
environment is still acting odd.

This feels like something has gotten cached that works for the filter URL but 
not for my direct one. Anyone have any idea what's going on here?

Thanks again,
Ron
_ARSlist: "Where the Answers Are" and have been for 20 years_
_ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Re: ticket direct URLs and login sessions

2013-02-26 Thread Nikolay Fedoseyenko 
Hi Peter,
Few things :)
In the system generated link:
http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=NTE%3aNotifier&server=AR_SERVER&eid=NTS00772848


the NTS00772848 stand for entry id in default request id or in the case of 
NTE:Notifier the Notification ID field id 1 (NTS just a prefix in the field), 
so &eid= stands for bring record number(entry id) NTS00772848

On the HPD:Help Desk form the Incident ID is not Entry ID which has field ID 1, 
so you can't use &eid=  and have to use &qual= qualification instead with 
encoded qualification string where you refer the field by name or by db id. 
You got it almost right, but looks like you have ' and a space that should be 
encoded in your link. 
Try this
http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Desk&server=AR_SERVER&qual=%27Incident%20ID*%2B%27%3D%22INC_NUMBER%22


Or this by field ID:
http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Desk&server=AR_SERVER&qual=%27100161%27%3D%22INC_NUMBER%22


Also, check that MID_TIER server name is the same in the link and in the path 
when your user logged in. Could be host name in one and FQDN in the other.

By the way the encoder is at 
http://:8080/arsys/shared/ar_url_encoder.jsp

Hope this helps
Nik



 From: "Peters, Ron" 
To: arslist@ARSLIST.ORG 
Sent: Tuesday, February 26, 2013 10:48 AM
Subject: ticket direct URLs and login sessions
 

**  
Hello,
 
We recently updated our notification templates to contain HTML direct links to 
incidents and changes. We disabled the default link at the beginning of all 
messages and created our own. An example of our INC URL is this:
 
http://MID_TIER:8080/arsys/servlet/ViewFormServlet?form=HPD:Help+Desk&server=AR_SERVER&qual='Incident
 ID*%2B'%3D%22INC_NUMBER%22
 
This is the odd behavior and it happens in all browsers.
 
· If a user is not logged into the mid-tier, the link requires 
authentication and then they’re taken directly to the Incident. Normal and as 
expected.
· If the user (not already logged into the mid-tier) uses the direct 
link, logs in, accesses the ticket AND THEN (without logging out) clicks on 
another direct link from a different email notification (or the same), they are 
taken directly to that ticket without any required authentication. Normal and 
as expected.
· If the user had already been logged into the mid-tier, the direct 
link in the notification still requires authentication instead of taking them 
directly in. Odd
o   If the user declines the authentication (closes the browser tab/window) and 
goes back to their original, already logged in session, that session has now 
been logged out and they have to re-authenticate (Session is invalid or has 
timed out. Please reload page to log in again. (ARERR 9201)). Annoying
 
Now, I’ve done some more testing. I re-enabled the ‘Add URL’ on the 
notification filter that has the form of:
 
http://MID_TIER:8080/arsys//servlet/ViewFormServlet?form=NTE%3aNotifier&server=AR_SERVER&eid=NTS00772848
 (ß I don’t know what the NTS number relates to)
 
The new notifications (in Dev) have both URL types. With this being the case, I 
can’t make it fail as before. I’ve also re-removed the ‘Add URL’ from the 
filter and it still won’t fail in that environment though our production 
environment is still acting odd.
 
This feels like something has gotten cached that works for the filter URL but 
not for my direct one. Anyone have any idea what’s going on here?
 
Thanks again,
Ron
_ARSlist: "Where the Answers Are" and have been for 20 years_

___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"