Expand my Community achievements bar.

SOLVED

403 on /nl/jsp/soaprouter.jsp

Avatar

Level 1

Working on a (first time) test install of campaign v7 on a Debian 8 server and after following the install instructions, I get the following when I try connecting the console program for initial configuration. "403 Forbidden: You don't have permission to access /nl/jsp/soaprouter.jsp"

campaign-error.gif

Not sure where to go next.

1 Accepted Solution

Avatar

Correct answer by
Level 10

Hi Leh,

Please may you execute this URL:

http://<domainname>/r/test

r/test is the more raw URL test to check your access/network configuration.

Regards.
J-Serge

View solution in original post

13 Replies

Avatar

Level 10

Hello leh,

Please may you check with your Adobe Campaign administrator the security zones section in the serverConf.xml file?

Your IP address (public or private) should be declared as a range in the LAN+VPN element. Usually it is done through an IP private addresses range in order to allow a company department (few people) to accede the AC with the Adobe Campaign client. And larger range for other accesses.

Regards
J-Serge

Avatar

Level 1

I think you're on the right track, but sadly, I added the IP and reloaded the config with the same results. I then went and added our entire IP range for giggles. Still nothing.

Seeing no errors in the Apache log, and the access log is showing the request coming in, and being denied, from an expected IP address.

Avatar

Employee

Hi Leh,

I think of a couple of things.

1. The operator you are logging in with does not have rights to access the server via the console.

Can be checked under access management for the operator for the checkbox forbid access from rich client.

2. The url being supplied in the connection is wrong.

Can you please share these two details

Regards,

Adhiyan

Avatar

Level 1

Sure,

I'm logging in as internal as I'm in the initial configuration state https://docs.campaign.adobe.com/doc/AC/en/INS_Configuration__Creating_an_instance.html

I do know the internal password and I did make sure to put my ip in the zone that allows internal to log in.

connection url is the ip address and port that Apache is listening on. Again, I'm seeing the requests in Apache's access.log.

Avatar

Employee

Hi Leh,

Probably there is a limitation on connections over http . Can you format the connection url to use https like https://10.42.98.xx and give it a try.

Also , try to open this link in a browser and try to login  <server_url>/xtk/dashboard.jssp. This will rule out issues with the local client console if any.

Regards,
Adhiyan

Avatar

Correct answer by
Level 10

Hi Leh,

Please may you execute this URL:

http://<domainname>/r/test

r/test is the more raw URL test to check your access/network configuration.

Regards.
J-Serge

Avatar

Level 1

/r/test responds with <redir status='OK' date='2017-12-20 14:16:10.955Z' build='8795' instance='default' sourceIP='x.x.x.x' host='x.x.x.x' localHost='campaign-test-app'/>

Avatar

Level 10

Hi leh,

So it means there are not physical or Windows firewalls issue, nor network routing one, nor Apache or Tomcat misconfiguration.

It was quite obvious for Apache, seeing nothing in its log file (access.log).

Now, you should check again the serverConf.xml file to understand the issue.

But beforehand, please repeat the steps of installation checks.
The soaprouter can't be acceded directly, except if you provide the credentials as post parameters (login or better token session). See API documentation for that.

So the easiest way to check is to use the Adobe Campaign client, or the web version of Adobe Client:

http://yourinstancedomain/nl/jsp/logon.jsp?target=/xtk/dashboard.jssp

Regards
J-Serge

Avatar

Level 10

Hi Luis,

Please let us know if you managed to find the cause of your issue.

Florent

Avatar

Level 1

I got pulled away with end of year activities, but plan to get back to this at some point this week, but no, have not figured out what I'm missing yet.

Avatar

Level 10

Hi,

Were you able to find something relevant for your query here?

Gaurang

Avatar

Level 1

I had this same problem and checked the error log for apache (httpd.service) and found the same repeating error every time this message was thrown (in browser and in my client login)- in my instance the issue was apache permissions. The fix was creating a new <Directory /[dirname here]/> block that granted permissions to all users cascading down from the earliest relevant folder.

I can't say if this is the answer you're looking for but the symptoms seem the same down to the /r/test returning success but still getting the exact same 403's.

Avatar

Level 4
I am also getting the same problem Did you find any fix ? It seems permissions related