cancel
Showing results for 
Search instead for 
Did you mean: 

Custom sign-in pages are not loading

Occasional Contributor

Custom sign-in pages are not loading

I'm trying to customize the login page:

 

- created a new sign-in page

- downloaded the sample zip, extracted it

- edited LoginPage.thtml

- zipped the files again

- uploaded the zip package to the sign-in page (validation was ok)

- ensured that a realm used this custom sign-in page

 

but when going to the realm it always shows me the Juniper default login screen.

 

If I select a "normal" sign-in page it works fine, it is just these customized pages that are not working.

 

I can even go and download the current zip package back and check that LoginPage.thtml is what I meant to be, but it is not shown by SA.

 

What am I doing wrong with the custom sign-in page?

 

SA 7.2R4

10 REPLIES 10
Highlighted
Super Contributor

Re: Custom sign-in pages are not loading

It sounds like you are taking the correct steps.

 

Just to make sure, can you attach screen shots of the following pages -

  • Page showing the custom sign-in file (date loaded and size)
  • Sign-in policies page showing assignment of the sign-in page with the custom pages to the specific realm.

I know this is trivial, but have you checked in the user log to make sure the user is getting assigned to the correct realm?

 

Ken

Highlighted
Occasional Contributor

Re: Custom sign-in pages are not loading

Hi Ken, thanks for your questions. I have here attached the screenshots you requested.

 

I am positive that the test connection is in the correct realm as I can change the sign-in page option in the sign-in policy and it is immediately reflected to the user interface. When using the built-in sign-pages that is! I can create a new sign-in page with just customized top logo and that is shown correctly. But when I create a custom sign-in page and edit the thtml files they are not showing. Instead the Juniper default page is shown.

 

Somewhere I read that if the version number in the thtml page is not correct then SA just ignores the file and uses a default page for that file. But what is the correct version number? Currently it says "<%# NetScreen Page Version 1002 %>" in LoginPage.thtml. I haven't changed it, it is just like it was in the sample.zip package that I just downloaded from the device.

Highlighted
Super Contributor

Re: Custom sign-in pages are not loading

Here is a guess - there is a syntax error in the preprocessor statements in your LoginPage.thtml page.  The custom sign-in page mechanism is working correctly, as you see when you load a trivial sign-in page.

 

I'm not sure how complete the checking is when you load a new set of pages - I know it checks for certain variables, but I am not sure if it checks syntax.  I think the manual on custom sign-in pages has some information about testing pages outside of the SA.

 

Ken

Highlighted
Occasional Contributor

Re: Custom sign-in pages are not loading

How could I possibly know what kind of syntax errors Juniper have included in their own html templates and how to fix them?

 

I mean, I just download their own sample.zip, only edit one thtml file in the package (change an URL in the img link), and then send the zip file to the SA cluster. I haven't touched the variables or versions or anything. The custom sign-in page is definitely not showing in the portal. Only the pages that are built-in in the system (the ones that you can change the top image, top background color and the title texts) are working fine.

 

I guess I need to open a case with the customers supplier who can open the ticket to Juniper. Nested support contracts are not ideal... :-/

 

Markku

Highlighted
Super Contributor

Re: Custom sign-in pages are not loading

There are no errors in the Juniper templates.  I suggested this because I did not know that your change was a very simple one not affecting any of the preprocessor codes.

 

Here is another thought.  I know that - if there are syntax errors in a custom login page - the Juniper will redirect to the default page (that is, the one matching the "/*" policy).  I don't know if that would occur if the URL in the img link was not found, but I would guess that it would happen if you had mismatched quotation marks.

 

Otherwise, I am out of ideas, and I guess you'll need to go to JTAC.

 

Ken

Highlighted
Occasional Contributor

Re: Custom sign-in pages are not loading

Hi, in this case it is definitely not redirecting to the main realm (/), the session stays in the testing realm (/mytest) but just does not show my custom thtml.

 

The support contractor confirmed that they were able to reproduce the situation with their device and thus they are opening a JTAC ticket. Let's see how it goes.

 

Markku

 

Highlighted
Super Contributor

Re: Custom sign-in pages are not loading

The realm does not change.  If the custom sign-in page assigned to a particular sign-in policy does not load correctly, the user gets redirected to the page for the default policy.  I think the only way you might be able to see this is to do a httpwatch in the browser to see what is fetched.

 

Ken

Highlighted
Occasional Contributor

Re: Custom sign-in pages are not loading

Ok, I don't see anything suspicious in IE9 developer tools' network capture. When going to /mytest there is the normal redirect to /dana-na/auth/url_10/welcome.cgi. This seems to happen in each realm, just with a different "url_XX" number.

 

Markku

 

Highlighted
Occasional Contributor

Re: Custom sign-in pages are not loading

Hah, stupid mistake from me... When I was searching the correct template file to edit I understood that LoginPage.thtml would be the correct one because there simply wasn't any other filename that could fit the situation. But actually the correct file was something else, something with "Notif" (notification) in it. I misread that it was "NotIf" (not if) and disregarded the file based on that description. (I don't have the files currently with me so I cannot tell specifically right now.) Today I found out the correct file. I need to continue testing later but that seemed to solve the mystery.

 

Markku