Guys,
In 4.1.0 and 4.1.0.1. We require users send us POST request with data in
the http body.
Ex:
POST https://cam/cisco_api.jsp
User-Agent:xxx
Other-Http-Header:xxxx
op=adminlogin&admin=admin&passwd=cisco123
Request with POST method and GET style query string is not supported in
4.1.0 and 4.1.0.1
Ex:
POST https://ca,/cisco_api.jsp?op=adminlogin&admin=admin&passwd=cisco123
User-Agent:xxx
We will try to allow the second case in the upcoming releases so that we
don't need to spend time educating customers the correct POST method we
required.
Regards
Prem
-----Original Message-----
From: Cisco Clean Access Users and Administrators
[mailto:[log in to unmask]] On Behalf Of Michael Grinnell
Sent: Wednesday, February 07, 2007 12:41 PM
To: [log in to unmask]
Subject: Re: 4.1 and API
Alex,
We use the API on 4.1 and haven't had any problems. We're using the
HTTPS POST method from perl.
my $CCA_Manager = 'https://ccamanager/admin/cisco_api.jsp';
my $ua = LWP::UserAgent->new;
$ua->agent(VERSION);
# Create a request
my $req = POST $CCA_Manager,
[ admin => $CCA_Admin,
passwd => $CCA_Passwd,
op => 'addmac',
type => 'userole',
role => $role,
mac => $mac,
desc => $descr
];
# Pass request to the user agent and get a response back
my $res = $ua->request($req);
# Check the outcome of the response
if ($res->is_success) {
if ( Check_CCA_Error($res->content) ) {
return 1;
} else {
return;
}
Let me know if you want me to try anything in particular.
Michael Grinnell
Network Security Administrator
The American University
On Feb 7, 2007, at 11:42 AM, Lanstein, Alex C wrote:
> Is anyone using the API on 4.1, using curl or otherwise? And has it
> working?
>
> Somewhere between 4.0 and 4.1 (we're on 4.0.4 and its not there),
> cisco decided it would be a good idea to add a rewrite for /admin to
> [R] to /admin/main.jsp. Sounds cool, makes it a little easier from
> the web (can just go to https://cam/admin and it will work), blah blah
> blah, but it breaks the api from what i can tell.
>
> Either when doing a straight HTTPS POST by hand, or by using cURL, I
> get the following header output:
>
> HTTP/1.1 200 OK Date: Wed, 07 Feb 2007 16:23:29 GMT Server: Apache
> Set-Cookie: JSESSIONID=D43B996........868D99FE87; Path=/admin; Secure
> Content-Length: 56 Content-Type: text/html;charset=ISO-8859-1
>
> So clearly, apache is recognizing this as /admin, and not /admin/
> cisco_api.jsp, and thus redirects the post to main.jsp. That's why
> all you guys see the login box when you try to use the api. it's
> actually main.jsp.
>
> Prem says that it's not an issue, as from the command line he seems to
> be able to get it to work. I'm not on 4.1...so if there's someone
> that is and is having api issues, if you could try:
>
> curl -k -d op=addmac -d mac=00:01:02:03:04:05 -d admin=admin -d
> passwd=cisco123 https://your_cam/admin/cisco_api.jsp > out
>
> then just cat out and copy the results in here, I'd appreciate it.
> the terminal may be a little screwly if you just try to do it with
> curl to stdout instead of redirecting it.
>
> if you're using trying to use the api, you can either copy the api to
> a different directory (say, /wlan/), or edit ssl.conf and remove the
> rewrite, that will fix it. If it were me I would just copy the api to
> a different directory and POST to there Regards,
>
> Alex Lanstein
> Senior Software Engineer, Transitional Data Services Help Desk/Network
> Junkie, Connecticut College Chief Coffee Drinker, LBCCHosting
> 860-625-4277
> [log in to unmask]
>
> ________________________________
>
> From: Cisco Clean Access Users and Administrators on behalf of Sean A.
> Thomas
> Sent: Wed 2/7/2007 9:50 AM
> To: [log in to unmask]
> Subject: Re: US DST Timezone Changes, CSCsg44268, /etc/localtime?
>
>
>
> My Unix admin team suggested that I run the command:
>
> /usr/sbin/zdump -v EST5DST | grep 2007
>
> I did so on my cam's and cas's (as well as my local linux boxen) and
> all checked out. I'm not sure which is the "most correct" way to
> check.
>
> Sean
>
>
> ________________________________
>
> Sean A. Thomas, MCP, RHCT
> Academic Systems Administrator
> Embry-Riddle Aeronautical University
> [log in to unmask]
> 386-226-6193 - Office
>
> You asked for it...learn more about ERNIE at http://it.erau.edu/ernie.
>
> -----Original Message-----
> From: Cisco Clean Access Users and Administrators
> [mailto:[log in to unmask]] On Behalf Of Mike Diggins
> Sent: Tuesday, February 06, 2007 5:24 PM
> To: [log in to unmask]
> Subject: Re: US DST Timezone Changes, CSCsg44268, /etc/localtime?
>
> I've been using this command to check:
>
> zdump -v Canada/Eastern |grep 2007
>
> which returns the correct DST settings on my CAM and CAS. Your command
> returns the correct settings on my CAM, but the old DST settings on my
> CAS.
> Which is right?
>
> -Mike
>
>
> On Tue, 6 Feb 2007, Bruce A. Locke wrote:
>
>> I was poking around our CCA Manager server to see if the version of
>> Fedora Linux that it uses was updated for the upcoming changes to
>> Daylight Savings Time in the US.
>>
>> The output of "zdump -v /etc/localtime | grep 2007" on our system
>> shows:
>>
>> /etc/localtime Sun Apr 1 06:59:59 2007 UTC = Sun Apr 1 01:59:59
>> 2007 EST isdst=0 gmtoff=-18000 /etc/localtime Sun Apr 1 07:00:00
>> 2007 UTC = Sun Apr 1 03:00:00 2007 EDT isdst=1 gmtoff=-14400
>> /etc/localtime Sun Oct 28 05:59:59 2007 UTC = Sun Oct 28 01:59:59
>> 2007 EDT isdst=1 gmtoff=-14400 /etc/localtime Sun Oct 28 06:00:00
>> 2007 UTC = Sun Oct 28 01:00:00 2007 EST isdst=0 gmtoff=-18000
>>
>> The file does not contain the DST update. But the copy of the
>> New_York timezone file in /usr/share/zoneinfo/America/New_York does:
>>
>> /usr/share/zoneinfo/America/New_York Sun Mar 11 06:59:59 2007 UTC =
>> Sun Mar 11 01:59:59 2007 EST isdst=0 gmtoff=-18000
>> /usr/share/zoneinfo/America/New_York Sun Mar 11 07:00:00 2007 UTC =
>> Sun Mar 11 03:00:00 2007 EDT isdst=1 gmtoff=-14400
>> /usr/share/zoneinfo/America/New_York Sun Nov 4 05:59:59 2007 UTC =
>> Sun Nov 4 01:59:59 2007 EDT isdst=1 gmtoff=-14400
>> /usr/share/zoneinfo/America/New_York Sun Nov 4 06:00:00 2007 UTC =
>> Sun Nov 4 01:00:00 2007 EST isdst=0 gmtoff=-18000
>>
>> The timestamp on /etc/localtime matches the day we did the
>> destructive reinstall up to 3.6.0(?) which was on December 29, 2005.
>> The timestamp for /usr/share/zoneinfo/America/New_York was on May 11,
>> 2006.
>>
>> It looks like the tzdata package was updated somewhere around CCA
>> 4.0.4 and the update did not contain the corresponding glibc-common
>> upgrade from Fedora. The glibc-common package usually has a trigger
>> that updates /etc/localtime if tzdata is also updated. So unless
>> such a trigger was added to tzdata in Cisco's forked version or put
>> in the update script for CCA then /etc/localtime will never be
>> updated. I don't see such an update in their script but I could have
>> very well missed it.
>>
>> Is this a known issue? The resolved caveats list for 4.0.3.3 shows
>> CSCsg44268 but shouldn't /etc/localtime be updated for that? Has
>> anyone else seen this on their systems? It may very well be a fluke
>> with our local environment but I just want to be sure.
>>
>> Thanks.
>>
>> --
>> Bruce A. Locke
>> [log in to unmask]
>> HAB 50 - (845) 257-3809
>>
>> Network Administrator
>> Computer Services
>> State University of New York at New Paltz
>>
>
>
> _________________________________________
>
> Mike Diggins Voice: 905.525.9140 Ext.
> 27471
> Network Analyst, Enterprise Networks FAX: 905.528.3773
> University Technology Services E-Mail: [log in to unmask]
> McMaster University, Hamilton, Ontario
|
