I have some problems logging to a site using CURL.
I think my problem is related to cookie file.
I use cookiejar when I'm logging in to collect the information and then
I use cookiefile to retrieve the information.
The problem is that from some reason the SMIDENTITY is added to the GET request from the browser and my CURL GET request does not contain such thing.
How do I get the SMIDENTITY value?
Do I need to include the __UT* stuff?
Here is what was going on from the brower side:
GET https://direct.orange.co.il/selfservice/customer/bill4u HTTP/1.1
Host: direct.orange.co.il
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Referer: http://www.orange.co.il/he-il/support/InnerHelpAssistence_lobby/
Cookie: __utma=242473949.486197456.1287994666.1288193684.1288790469.7; __utmz=242473949.1288176356.3.2.utmcsr=bill4u.orange.co.il|utmccn=(referral)|utmcmd=referral|utmcct=/action/mainAction; __utmv=242473949.|1=VisitorsStatus=LoggedInClient=1,; SMIDENTITY=BTDjG3qPjKo2JuOv2Kpny5x67dINOqb769XHS+ha7VNtqmmNSSHPlKhwQU/5sQmk9LdGud2nmf0ycs+yiZsU3Bc84Q9o7tJHN1BeuR7Q/49VA936+twTqsTPW/6+bR9Xk0Mcz94EsyovINIHGbC0FTbk7Lu9LcYlBoUMhOrt38NQ6spJubzVXQHNjZ1ah4wRWSLC0fcHHR0YA0sfHi6wc//wd31CNJxJOzCEX3aKmmMMgEVY4rjlKLu9SDDaQy3IqS+nZDcni1i1mUN9XrSg++dG7JNKWE5GFiZYsU9trcSJPfluFr4CBTKshmQziX8/oLIlUQrdu8XtC/p+MiKIv7AFhh0N8f8wZHcqcthgokXPo8Pe7v3W8PRkEyBqVhVFAt+oILmwGihySU8of5JDAdC/ZW/GuX42wZy6dIvNPdtcHzZXEV7yoiRElFplyFYzbt/w2kkJXI745nwY0R99RfK41o/tDdZq9t4Vh/zLqyZpGlqrc5n+6WmoX+eH6x7Kc/7KsycqbqUheVkpMqhMB7jbiMR9sVV27G0BJd2AL1mO6DNImrg5oB3hbs5cXVeiRaJSqJEXe2D2nmwzlFTlWsMEortuv3q/; __utmb=242473949.24.10.1288790469; __utmc=242473949; SMSESSION=1fXQyP10q6P5cAYfxnKws3NULK6iKjlX1lhtCzXJbCy2tpIFvPwObyaNQdV/HZ1m/ijgY8C0tWdVp9LHuIumQsEh94m8wLF6epNrU8/01Ac9ePCy/ArMR/ur3u0bchyzbWkD4q60qGzKojyqrkRedJ6eWHLz3pxFxbHkiDGxfor66heZYIZFR7aFzYBcH7XjR8dEju8sWJoM5+eRDE7OTw5oxYCzJi2w5kLD7PzpWc9yVOCK0hVuvjQTuln+RfhPzzB/yniBQCJDJt/Zk8wk8/Bs1Ks4M8wBMobAbywMTe+gSQkwZBqGhEu72QFa9F3+TLbzERr6ovLbU89OrguJTCP8aXcObRhiluqc47ZaBvIUFhBhX6l4+YXlMimJLtjG5+tBwgqbggZkI9zbzja13kl5Lhdl234Zn4WppmNy3EkpEIbX6BUtkxtwGaRieKFXpzui7cFzg/3MHXcWki+7accjryvuPOviHa9dn6VLXbnHJIFjo6KaqCHU/PjbObyGCy6QXA2d15J5rS9mLfWHrCVjWGLTqEqT/Knhy2rOHhQqHBeYrYyCgA0bdfcfo2Dfxqkb2cMNpB9UbqccGKwGsN1hMYhWkGPO29EQ6VTa+SXTwtnCLO18rYxjuYIH9PBbvndpLq+yfmPUAUw2KAIyB+hrwYtB5nn+IC1pXicyJkjN93lnc4R91BGJkWnC8bK7QoRERwM9+mww0QmcEkjp2sQd70PE7Xj0zQ02Gb0k9uL831B5Hvd4t2YM5PTFMRFAmR7BILYnqad/YeqIHAz1h9XX4tsXlKCICHn1ujmQbP5OwOoYaxIdRTQ2HWloJKmfdQ5PYs/Um8i5nOtvFbRCIor2QCRHPqMlMpwEseqSkJSzzOUaJMzlAMMfqR2gxz31W0uRZ5uhMoe8mMps4ZFLC462aGiw0vHOVDqXuKdqed+M54WLvo+PtF2x4V86/COspRZAqWmcBiAg+OnByQOSS5UAScE+RaB9MrY6ac22EWSSo6TNcZI7mDm/yejRA/SSwMpTWMxXg2aFnGI21fnmFFS7yZYWIRVTXYlr+PJ3RpqSFVch+sKQ3pVj/gP+E00nTtqtkGRBjL1bFJlxThCopkqbu8+UBxJk; JSESSIONID=MRvhpHlnRZ9Hps2JcX8kvpQNLRGKRTksCRyTQQkNG82Gkfj8yHGg!574440962
And this is from my CURL request:
GET /selfservice/customer/bill4u HTTP/1.1
Host: direct.orange.co.il
Accept: */*
Referer: https://registration.orange.co.il/copa/pages/protected/protectedredirect.aspx?original=http://www.orange.co.il/
Cookie: SMSESSION=gKf3lG8FdhNz+pezIUshjM42Hz1hhPssLATeIYZnLCi1iohEqpMo7H86kO4GtSTIfF04Fnu++qYlIkb+DAbMTwxd/pTEOsh94F/2iAaHqS2gSWn1dbWhlcasKAxBP7kYohdgDGsx5B90JBtbJQg0dj9Y305pcBhMjXnqcsuSEo/WzRNn/GAWoaaGJPwmFy9DSofVWB3/RZmaiugdOtWw8mJfneQNiui2Xvqx5PES9hnBx+fQNXKB6kaJPLFt0qsX4Atp5EhgJnbs6bOPPQaYc2FmmJF9YnNeHPsvPZJEcHf7FV75NGZN7760G6tFRC43mTO522CI5VB+QohM/AjUbILg1EJgnbSaDy8m/OVha+jMOsI11ZzYSSeR4f8SFd8gtlBVWe2UbWwocHqLJmvrw6rAOHt1WKU5EhBOGzfb2LYGjTHODLLcOx9PiCXaEzD/HKYlE17Yxec238+bE5qXtfmHPzxkCHdT7M7wC2/YpVucRYalc+lcMVvk7vENiAg1aXDvxl3K9YxUGDdngkF+CtkjdDqYP/R9SrKnd5kP36oCop8mRFPNsO30hXjHXCBSZgNoDA4/YkPEFJ68KLWXJUbgzSRwmF5c38ntlgC5kapc2XWREYqIkzCrdFbXLzP+1BZpOVaOe8umU/jMwCC8lgNilU+hA8qRSZJtB3Ni4oAdLe0Sgq28A6r2pngF0yrTVqlasRYQP1+ud6Z2uRqHQv4nEKh45sHi6fBeAFaVOo/Yp/B49/fnzd6SRC6JUT5r1vToluD2f/AouJAtV6zkeyXN0YP5njHVhpq2sCdB/3Iap8hJ+386pmzAFBTquJ6ko5BpII0Zhsy4YGa7OUh+1bt4e0WuUC0nzsckENrXtJphiJQEUDAQ63xTBKTegGKOtdWRfbEAj1QE7E7LSrIubWn9T92vRQdF63l3aX6LwegoiLqRa9092ILP94R3mt7J+UVmwUgHcX4K91yqqhSqYJOs6TlShIB2htYCB/+KCvkT4bnv+PlFB1SbPzCNdMK687rd7cKcsZ4KN/IaUzRBhckBuxujTta53y5WejTbI2VecOXHFV9QKWIdDhRzhay5YgVwBzt5XEHWXoYy1z67nunIku5dbKfc;
JSESSIONID=MHmJyFmbNZJxLpprzDW4m0d3Z90RYQdZ6rzzLWTtdLy4H1HBf7VP!-1366797818
How do I overcome this issue?
Thanks
Instead of curl how about use a tool that is meant for this kind of use case, such as mechanize.
Related
A couple of days ago in Power BI, I was able to create a web query that allowed me to extract the JSON data from NBA Player Stats without using any headers. As of today, I have noticed that the query no longer works; I am getting the following error message:
DataSource.Error: The underlying connection was closed. An unexpected error occurred on a receive.
Details: https://stats.nba.com/stats/leaguedashplayerstats?College=&Conference=&Country=&DateFrom=&DateTo=&Division=&DraftPick=&DraftYear=&GameScope=&GameSegment=&Height=&LastNGames=0&LeagueID=00&Location=&MeasureType=Base&Month=0&OpponentTeamID=0&Outcome=&PORound=0&PaceAdjust=N&PerMode=PerGame&Period=0&PlayerExperience=&PlayerPosition=&PlusMinus=N&Rank=N&Season=2019-20&SeasonSegment=&SeasonType=Regular+Season&ShotClockRange=&StarterBench=&TeamID=0&TwoWay=0&VsConference=&VsDivision=&Weight=
On a related note, I used to be able to pull the JSON data from NBA Team Stats using https://stats.nba.com/ as a Referer header, but now it's giving me the same error message as shown above. To try and get around these errors, I have tried entering the following headers:
Host: stats.nba.com
Connection: keep-alive
Accept: application/json
x-nba-stats-token: true
User-Agent: Chrome/79.0.3945.130
x-nba-stats-origin: stats
Referer: https://stats.nba.com/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
When I do submit the query with the above headers, it comes back with the following error message:
Unable to connect
We encountered an error while trying to connect.
Details: "The 'Host' header must be modified using the appropriate property or method.
Parameter name: name"
I have run out of ideas as to how I'm able to properly run the query. I'm really new to web-scraping and HTML -- I've been trying to teach myself. Any help is greatly appreciated.
All headers for GET request:
Host: stats.nba.com
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Accept: application/json, text/plain, */*
x-nba-stats-token: true
X-NewRelic-ID: VQECWF5UChAHUlNTBwgBVw==
DNT: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36
x-nba-stats-origin: stats
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Referer: https://stats.nba.com/teams/traditional/?sort=TEAM_NAME&dir=-1
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US;q=0.9,en;q=0.7
URL:
https://stats.nba.com/stats/leaguedashteamstats?Conference=&DateFrom=&DateTo=&Division=&GameScope=&GameSegment=&LastNGames=0&LeagueID=00&Location=&MeasureType=Base&Month=0&OpponentTeamID=0&Outcome=&PORound=0&PaceAdjust=N&PerMode=PerGame&Period=0&PlayerExperience=&PlayerPosition=&PlusMinus=N&Rank=N&Season=2019-20&SeasonSegment=&SeasonType=Regular+Season&ShotClockRange=&StarterBench=&TeamID=0&TwoWay=0&VsConference=&VsDivision=
Required Headers:
Accept: application/json, text/plain, */*
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36
x-nba-stats-origin: stats
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Referer: https://stats.nba.com/teams/traditional/?sort=TEAM_NAME&dir=-1
Not sure if required:
x-nba-stats-token: true
X-NewRelic-ID: VQECWF5UChAHUlNTBwgBVw==
Possible problems:
You detected as a bot and blocked
Header X-NewRelic-ID is a token (maybe with timeout). Probably it's assign using different params like IP, User-Agent and among others.
You can get fresh X-NewRelic-ID in HTML response with GET request to https://stats.nba.com/.
Here is a part from HTML with xpid token:
<script type="text/javascript">(window.NREUM||(NREUM={})).loader_config={xpid:"VQECWF5UChAHUlNTBwgBVw==",licenseKey:"09f0cb5c68",applicationID:"76210961"};
On Thursday (2017-04-26), I began seeing the following error when I logged into my application using my Authenticator JSF page.
[#|2017-04-30T15:18:51.649-0500|WARNING|glassfish
4.1|javax.enterprise.web|_ThreadID=30;_ThreadName=http-listener-1(2);_TimeMillis=1493583531649;_LevelValue=
StandardWrapperValve[Faces Servlet]: Servlet.service() for servlet
Faces Servlet threw exception
javax.faces.application.ViewExpiredException:
viewId:/security/Authenticator.xhtml - View
/security/Authenticator.xhtml could not be restored. at
com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:212)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at
com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:123)
at
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198)
My Authenicator.xhtml page is backed by a Authenticator.java class with the following header.
#Named
#ViewScoped
public class Authenticator implements Serializable {
During my research, I discovered the following:
I am able to log into my application using Chrome 58.0.3029.81 one time after restarting the computer running the GlassFish 4.1.2 server. If I log off, I will get the above error on every future log in attempt. (This is a weird one.)
I can log in using Internet Explorer
I can log in using Chrome versions older the 58.0.3029.81.
I can log in using Chrome 57.0.2987.132 on my Android telephone
I can log in using Chrome 58.0.3029.81 if I change the javax.faces.STATE_SAVING_METHOD variable in my web.xml file from server to client.
Why would Chrome 58.0.3029.81 kill the Authenticator view resulting in the ViewExpiredException?
As requested, I analyzed the network traffic and determined that Chrome 58.0.3029.81 sends two additional Get requests during the Authenticator.xhtml display process than Chrome 57.0.2987.133 sends.
Chrome 57:
GET /webapp/security/Authenticator.xhtml HTTP/1.1
GET /webapp/security/RES_NOT_FOUND HTTP/1.1
GET /webapp/security/RES_NOT_FOUND HTTP/1.1
POST /webapp/security/Authenticator.xhtml HTTP/1.1
Chrome 58:
GET /webapp/security/Authenticator.xhtml HTTP/1.1
GET /webapp/security/RES_NOT_FOUND HTTP/1.1
GET /webapp/security/RES_NOT_FOUND HTTP/1.1
GET /webapp/security/RES_NOT_FOUND HTTP/1.1
GET /webapp/security/RES_NOT_FOUND HTTP/1.1
POST /webapp/security/Authenticator.xhtml HTTP/1.1
Since I don't know why Chrome sends the RES_NOT_FOUND gets in the first place I don't know if sending two extra is a bad thing but it seems to be related to GlassFish 4.1.2 not being able to reconnect to the Authenticator view.
Could this be an issue with my Authenticator.xhtml page or is it a Chrome 58/GlassFish 4.1.2 issue?
The following is a comparison of the Post information:
Chrome 57 Post
POST /webapp/security/Authenticator.xhtml HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 205
Cache-Control: max-age=0
Origin: http://localhost:8081
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://localhost:8081/webapp/security/Authenticator.xhtml
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
Cookie: JSESSIONID=4067aa3d0df7f2bc26b8200a8c4a;
modena_expandeditems=j_idt32%3Awelcome-menu
authentication-form=authentication-form&authentication-form%3AuserName=XXX&authentication-form%3Apassword=XXX&authentication-form%3Aj_idt93=&javax.faces.ViewState=-4577625721740212982%3A4298605796688550126
Chrome 58 Post
POST /webapp/security/Authenticator.xhtml HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 204
Cache-Control: max-age=0
Origin: http://172.24.1.125:8081
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://172.24.1.125:8081/webapp/security/Authenticator.xhtml
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
Cookie: JSESSIONID=4089ef02f0bca32d331de1f5404f
authentication-form=authentication-form&authentication-form%3AuserName=XXX&authentication-form%3Apassword=XXX&authentication-form%3Aj_idt93=&javax.faces.ViewState=3383766421781608154%3A6418504070036764787
The only difference that I see is that Chrome 57 appended "; modena_expandeditems=j_idt32%3Awelcome-menu" after the JSESSIONID.
This turned out to be an issue with version 2.1.1 of the PrimeFaces premium theme called Modena and PrimeFaces 6. During HTTP analysis, I noticed that Chrome 57 sent 2 RES_NOT_FOUND requests and Chrome 58 sent 4 RES_NOT_FOUND requests. This was a known issue with Modena 2.1.1 as documented in the following PrimeFaces Modena Forum issue:
PrimeFaces Modena Forum Issue
During each RES_NOT_FOUND request, the JSESSIONID would change and something about the additional 2 changes in Chrome 58 would break the link between JSESSION and ViewState.
Upgrading Modena to version 2.1.3 eliminated all the RES_NOT_FOUND requests and resolved the ViewExpired issue.
I have an AngularJS WebAPI application.
As far as I can understand the OPTIONS request is constructed automatically by the browser.
POST http://localhost:3048/Token HTTP/1.1
Host: localhost:3048
Connection: keep-alive
Content-Length: 78
Accept: application/json, text/plain, */*
Origin: http://localhost:2757
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: http://localhost:2757/Auth/login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.8
grant_type=password&username=xxx%40live.com&password=xxx
Response:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 971
Content-Type: application/json;charset=UTF-8
Expires: -1
Server: Microsoft-IIS/8.0
Access-Control-Allow-Origin: *
Set-Cookie: .AspNet.Cookies=CpvxrR1gPFNs0vP8GAmcUt0EiKuEzLS1stLl-70O93wsipJkLUZuNdwC8tZc5M0o1ifoCjvnRXKjEBk3nLRbFlbldJLydW2BWonr5JmBjRjXZyKtcc29ggAVhZlc2E-3gGDlyoZLAa5Et8zrAokl8vsSoXmHnsjrxZw0VecB_Ry98Ln84UuKdeHlwSBnfaKKJfsN-u3Rsm6MoEfBO5aAFEekhVBWytrYDx5ks-iVok3TjJgaPc5ex53kp7qrtH3izbjT7HtnrsYYtcfPtmsxbCXBkX4ssCBthIl-NsN2wObyoEqHMpFEf1E9sB86PJhTCySEJoeUJ5u3juTnPlQnHsk1UTcO0tDb39g-_BD-I4FWS5GMwxLNtmut3Ynjir0GndwqsvpEsLls1Y4Pq7UuVCTn7DMO4seb64Sy8oEYkKZYk9tU4tsJuGD2CAIhdSc-lAmTAA78J5NOx23klkiuSe_SSiiZo5uRpas_1CFHjhi1c8ItEMpgeTsvgTkxafq5EOIWKPRxEHbCE8Dv106k5GlKK5BaH6z7ESg5BHPBvY8; path=/; HttpOnly
X-SourceFiles: =?UTF-8?B?QzpcR1xhYmlsaXRlc3Qtc2VydmVyXFdlYlJvbGVcVG9rZW4=?=
X-Powered-By: ASP.NET
Date: Tue, 13 Jan 2015 04:54:55 GMT
{"access_token":"TkJ2trqT ....
Now logged in
I log out which is nothing more than removing the token and log in again. Something happens that is different. Before it did not send the OPTIONS but now it does. Is there something resulting from a previous request/response that would influence the browser to act different the second time I log in?
OPTIONS http://localhost:3048/Token HTTP/1.1
Host: localhost:3048
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://localhost:2757
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Access-Control-Request-Headers: accept, authorization, content-type
Accept: */*
Referer: http://localhost:2757/Auth/login
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Response:
HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 34
Content-Type: application/json;charset=UTF-8
Expires: -1
Server: Microsoft-IIS/8.0
X-SourceFiles: =?UTF-8?B?QzpcR1xhYmlsaXRlc3Qtc2VydmVyXFdlYlJvbGVcVG9rZW4=?=
X-Powered-By: ASP.NET
Date: Tue, 13 Jan 2015 04:56:32 GMT
{"error":"unsupported_grant_type"}
If I do a browser reset and reload of the page then it goes back to like before where it does not send OPTIONS the first time and I am able to log in.
Probably I need to change something on the server so it handles options.
BUT why does my browser (Chrome) not send OPTIONS the first time?
Whether the Chrome (or any other browser) sends an OPTIONS request is exactly specified by the CORS specfication:
When the cross-origin request algorithm is invoked, these steps must be followed:
...
2. If the following conditions are true, follow the simple cross-origin request algorithm:
The request method is a simple method and the force preflight flag is unset.
Each of the author request headers is a simple header or author request headers is empty.
3. Otherwise, follow the cross-origin request with preflight algorithm.
Note: Cross-origin requests using a method that is simple with author request headers that are not simple will have a preflight request to ensure that the resource can handle those headers. (Similarly to requests using a method that is not a simple method.)
Your OPTIONS request contains the following request header:
Access-Control-Request-Headers: accept, authorization, content-type
This means that your Angular app has inserted the non-simple Authorization request header, probably as a part of an authentication scheme. Non-simple "author request headers" trigger the OPTIONS request, as you can see in the above quote.
To allow the request to succeed, your server should handle OPTIONS request and respond with:
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Headers: authorization
To learn more about CORS, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS.
When you first login you most likely set the Authorization HTTP header somewhere in your login procedure. On the other side, you forgot to remove this header when the user logs out.
When you try to login again, the Authorization HTTP header is still present. This triggers the browser to perform a preflight request (see explanation of Rob W: https://stackoverflow.com/a/27924344/548020. Considering that you try to login with a grant type password it does not make sense to send an Authorization header, as this implies that you are already authorized (= logged in). Your are basically asking your backend to log you in and at the same time telling your backend that you are already authorized (= logged in).
This can be fixed by simple removing the Authorization HTTP header when the user logs out.
You can also clean your Headers when you login, before sending your POST request:
delete $http.defaults.headers.common['Authorization'];
I am using the parameters for updating via Web service method.
Please see the post below.
Post: http://myweb.com:8241/web/Dashboard.aspx/BindDatatable
Host: localhost:8241
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json; charset=utf-8
X-Requested-With: XMLHttpRequest
Referer: http://myweb.com:8241/web/Dashboard.aspx
Content-Length: 49
Cookie: .ASPXANONYMOUS=ltv9ZiqjzgEkAAAANGZlZTY2ODItYmFkMy00OWI5LWIxMDktNGU5NTg4M2IyOTVj2fU3SjopgaEx5DOYla827v7hFQNzpmfoFvRqDv1859g1; ASP.NET_SessionId=1bro3mtv1gbcqswhlced251h
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Send Post Content?
{stat: "201541",search:"",points:"100",delete:""}
Is it possible to encrypt this post content? Or revise my code not to use json? I am just confuse about this, and i think i am about to build vulnerability here. Please help.
Encrypt? Sure, use HTTPS.
Protect? Against what? If you are concerned about someone posting whatever they want to your web service, or seeing how it works, there is nothing you can do to prevent that. All you can do is not trust data from the user.
Using Google Chrome I'm opening Flex4.5 Client that makes GET Http Request to Rails back end that renders back json response.
If the response is 4xx Client Error then Chrome Developer Tools network tab shows the request as canceled, and I can't access the response error message through the Fault content in Flex.
This happens only on chrome. It works fine for FF and IE or if I execute the query in the chrome browser.
Below are the request and response headers copied from Chrome Developer Tools
Thank you for your help
GET (canceled) application/json Other
Request Header
GET url HTTP/1.1
Host: localhost:3000
Connection: keep-alive
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.83 Safari/535.11
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Response Header
HTTP/1.1 404 Not Found
Content-Type: application/json; charset=utf-8
X-Ua-Compatible: IE=Edge
Cache-Control: no-cache
X-Runtime: 0.500000
Content-Length: 30
Server: WEBrick/1.3.1 (Ruby/1.9.2/2011-07-09)
Date: Wed, 28 Mar 2012 21:53:40 GMT
Connection: Keep-Alive