I'm trying to automate the website but the website is reading the cookies and after 5secs its redirect to the main page. (Just I assume, because I disable the cookies then refresh it, the website was not redirecting). I don't know how to set the cookies by using WWW::Mechanize.
Here are answers to the questions you've asked, but I don't think they'll help you a lot. You really need to explain what you're trying to do, show your Perl code, and describe the behaviour that needs to be fixed
Cookies are data that a browser client stores on behalf of a server. They are indexed by URL
Every time a client sends an HTTP message, it checks to see whether it has cookie data for the URL. If so then the data is included in the header of the message sent
How to find if the website is reading cookies
The cookie information that a client sends is always read, but there is no way at all to tell whether the server has taken action according to that information, or just discarded it
the website is reading the cookies and after 5secs its redirect to the main page
I'm unclear how you think cookies might be relevant
Just to be clear:
A website is an accumulation of data files and executables on a server system, and so cannot "read" a cookie
It is the client—your browser—that redirects to the main page. That is most likely to be because the last message from the server included an instruction to load the main page after five seconds
Related
I have a basic html, which contains a form. This form submission is handled by a RESTful backend api service (written in spring boot). The html page is unprotected for business reasons -any sort of authentication / login mechanism can't be applied on the HTML. How can I make sure, only the html is allowed to hit the backend APIs, and not other sources? Both the html and backend apis are under the same domain. Example - example.com/index.html; example.com/getStudentList
How can I make sure, only the html is allowed to hit the backend APIs, and not other sources?
If I'm understanding things correctly, you don't want consumers of your API to authenticate with the API, because reasons? But what you want is that any client that loads the index page can access the API.
The closest implementation I can think of that would work at all like that would be to treat the API urls like a one time pad: You dynamically generate the html page, with urls that include some difficult to guess token. When the API receives any request, it checks the token -- if there is no token, it rejects the request (403 - Forbidden). If there is a token, it checks whether or not that token is still active; if the token is expired, then the request is rejected. If the token is inactive, but within some grace period, you might redirect the API request to a URL with a newer token (301 - Moved Permanently). If the token is active, then you serve the request.
Mark Seemann, while trying to solve a different problem, wrote a nice little introduction: Avoiding Hackable URLs.
If that sounds to you like a session cookie -- well, you aren't far wrong. To be completely honest, I suspect that the differences are subtle, and I wouldn't be surprised to discover that I exaggerate them. The primary differences are that we are communicating things like cache invalidation and the resource lifecycle explicitly to intermediary components. The Cookie header, on the other hand, is effectively opaque.
This answer is certainly imperfect -- anybody who happens to guess the currently active URL is going to be able to access the API whether they hit the index page or not. Obscurity, rather than security.
But it might be enough to tide you over until you have reasonable requirements.
Background checks:
I read through several blogs but unable to find anything specific around this question.
Below is the architecture:
HTTPS website (no login needed) have common LIKE button.
Upon clicking, user enters email address and solves CAPTCHA and click SAVE button.
Rest call is made with data and DB stores the values.
Problem:
Now if someone try to call Rest from say POSTMAN, there is no way to authenticate whether call is coming from Https website or somewhere else.
Question:
Is there any way to ensure that Rest will understand whether call is coming from https site only in order to process request further?
I'm retrofitting my application with GWT History support, and I've stumbled on a case where I'm not quite sure what to do. The answer to this question doesn't necessarily have to be GWT-related.
GWT's History support functions by passing around hash tags (i.e. index.html#token). Security restrictions require users be logged in prior to actually being able to access index.html, so they get sent over to a login page, retaining the token (login.html#token). So far, so good. Now the user becomes authenticated and Spring sends them over to index.html (the default target) and eliminates the #token part of the URL.
How can I force Spring Security to maintain the token and send my newly authenticated user to the page they requested (index.html#token)? Since I've already got Spring Security authentication working, I'd prefer to not restructure the way my app handles logins.
After a great deal of digging, I found my answer on Spring's Jira. As Colin Alworth stated, that token isn't actually part of the request, so Spring Security never sees it server-side, and thus can't use it to determine the final URL. So the approach I used was to append the hash (client-side) to j_spring_security_check, making it j_spring_security_check#token. Now the token gets passed along just fine, allowing me to have a well-secured app with working tokens.
Thanks for your help Colin, your answer got me thinking in the right direction.
The server doesn't get to see this token as part of the GET/POST request as you've noted, it is only seen by the browser. Best fix that I've seen for this in the past is for the login page to take note of the current window.location.hash, and pass that along, either along with the login form (assuming a redirect will take place that keeps the hash around), or to the server as a login param so it can redirect properly.
Here's what happens, it might help you solve the problem:
sending unauthenticated users from index.html to login.html is most
likely implemented as an HTTP 3xx redirect, and that's why the
browser keeps the hash fragment (#token).
Once they login, spring sends them from login.html to index.html not
via 3xx redirect so the browser doesn't keep the token.
One solution would be to inject the token into index.html, and pick it up with GWT. Another one is to make login.html -> index.html a 3xx redirect (if spring allows that).
I want to delete record of those peoples who have remove app from their application's list, to do this I have entered that URL where I make a code to delete record of active user from my database in de-authorize callback. But still I'm unable to de-authorize users from by db.
Edit: See Facebook Deauthorize Callback over HTTPS for what my original problem really was. Summary: Improper web server configuration on my part.
Original answer was:
One potential problem has to do with https based deauthorize callbacks. At least some SSL certificates are not compatible with the Facebook back end servers that send the ping to the deauthorize callback. I was only able to process the data once I implemented a callback on an http based handler.
Some things to check...
That the URL of your server is visible from facebook's servers (ie not 192.168 or 10.0 unless you've got proper firewall and dns config).
Try using an anonymous surfing service and browsing to the URL you gave facebook - do you see a PHP Error?
Increase the loglevel for PHP and Apache/IIS to maximum and see if you get any more information
We can't do much more unless you give us your code...
I need to login to google to access a private spreadsheet through mIRC. I can store the email and password in a variable, no problem; I just don't know the easiest way to actually login - I want it fully automatic, no user prompt required.
I tried this so far, but it didn't work..
http://pastebin.com/r57KQ1DP
There is no easy answer, I'm sorry.
The google login is very complicated because:
It uses multible set-cookie lines in the header reply
It has hidden fields which seems to be used as security method (you would need to request the login site first and store those values and send them with the login-request to make your login-try valid)
You manipulate the cookie and how it's stored and sent in the next request, this can also have an effect to the login.
There is only one suggestion I can make to you: Download the firefox addon Live HTTP headers and try to follow what your browser sends and act like it.