I am trying to update an app that I wrote for Android that will automatically log a user into a captive portal at my university. The app worked fine last year with the portal URL hard coded in, however this year that won't work because they changed the server URL, I know what the URL is, so I simply changed it in my program ... which sort of works
There are two main problems, for me, with this approach.
hard coding is a pain in the ass to do every year, I also want to be able to make it future proof, so that hard coding the URL won't be necessary
for some unexplainable reason there are actually buildings on campus that will direct to the OLD authentication server, it truly boggles my mind why it would do that
I would like to be able to make an HTTP request and get the URL of the captive portal that is redirected to, how is that done?
Captive portals generally will intercept users' HTTP requests and issue a "fake" redirect to the portal's authentication page. Or they can simply replace the actual response with the login page.
If yours is a redirect-to-login, then simply do something like trying to load http://google.com, which can reasonably be expected to be truly available for at least the next few years. If the response comes in as a redirect to some totally different site, the redirect url is highly likely to be the portal's login page.
If it's a replace-the-response-with-login, then you should try to contact a known page with some known content, and see what you get back. if the response you got doesn't match you should have gotten, then you've gotten the login page and can try tearing apart the response and finding the login form via DOM operations.
Captivate portals uses 2 methods.
as described above. http redirect so the gateway takes you to another address.
ICMP - sending "better route" message
Still from my exprience on cases where non simple redirect happens the approach of expecting the redirect won't work.
Related
So, I have my script page and I want to get an output that generates on this page. It could've been done with default http client but the problem is that google requires authorization to access this page.
So how can I do it right?
I also asked about this before but now I realize that my question wasn't clear.
It is possible to post web app page to be accessible by "anyone even anonymous". So no auth is needed
I promised to do something, but my managers want assurance that it can be done. What seems like a simple task is surprisingly hard to find example of. It consists of:
The browser asks a Java servlet for access to a remote site.
The servlet opens a HttpUrlConnection to that remote site.
The servlet sends a login request to that remote site.
The servlet receives a login form.
The servlet populates the login form from user session data, then
POSTs it.
The servlet receives the "welcome" from the remote site, complete
with headers and cookies.
The request of step 1 is finally filled by the content, headers, and cookies from step 6.
I'm having trouble getting code examples, leading me to think that what I want to do can't be accomplished. Can someone point me to an example?
Thanks,
Jerome.
The main problem is the domain of the session cookie.
More accurately, the question is what you're planning next after step 7.
Say your servlet is at "https://mycompany.com/loginServlet", and the remote site is a toy store "https://toys.com". Were you hoping that after step 7, the browser could be redirected to "https://toys.com" and get a proper service befitting a logged-in user? This won't work because when the browser received a session cookie from "mycompany.com" (in step7), this cookie will be attached to further requests for "mycompany.com" - but not to "toys.com", it's a security feature for excellent reason.
In short, this approach might work if both the servlet and the toys site are on the same domain. Though it makes me a bit uncomfortable in terms of security and password management, but never mind.
Obviously this approach would also work in the (unrealistic) case of letting your server proxy all further requests from the browser to "toys.com", but that's unrealistic for a typical commercial site (due to relative/absolute links, ajaxes etc.).
If it's different domains, then I second the wise comment made by "Rahul B" above: please look into SSO, and/or check with "toys.com" what login mechanisms they offer - maybe they already have something like "login with google" that's convenient enough.
I have started to write a webApp in Eclipse where ECMAScript6 on the client (testing mostly on chrome on Win7) communicates with the server side written in Java7 on Jetty+GAEplugin via xmlHttpRequest (1 get request, user edits data, 1 post requests ). if it gets more I will move to webSockets).
The client code does not know anything about logins and provides neither user name nor password because as I understand, the browser and the user handle that. On the server side I response with 401 if basic authentication is missing.
But when testing, the browser does not ask the user for any password and does not send a second request (FF the same effect). No errors. Chrome development console claims that my
response.addHeader("WWW-Authenticate","Basic realm=\"bus driver\"");
did not reach it.
A subset of my targeted user baser does not have a google account nor FB nor twitter. So OpenId nor OAuth are of no use for that subset. OAuth doc says: " The user signs in using her Google account, .." . Any way I try to search, directs me to ways to store user data, but I have problems with the communication between browser and servlet.
I have read that I should edit web.xml, but I cannot see how to plug my home-built authentication into that. Web.xml would be okay for me because there will be about 3 pages sharing the same (*3roles=9pages).
My software should be up to date. Oracle claims that I should stop using Java 7, but I cannot get local GAE to run on Java 8 ...
Just testing on FF and looking for stupid errors I may have made last night. FF claims: InvalidStateError: An aatempt was made to use an object that is not, or is no longer, usable. Hmm seems that there is at least something wrong with my XMLhttpRequest (it worked in chrome at least without authentication). I could test GET with authentication but without ECMAscript... Still my main question remains, where is the example with old school authentication on the new kid, the cloud?
Logcat is empty. I have seen the logs getting filled in TomCat or for Android. I may have to dig into this.
I'm trying to make a e-commerce page and I have a login form in all pages (included in the header). What I whant is to do a secure connection between the client and the server when the user logins for the password don't be sent in plain text string. The problem here is I don't want to use https for all pages, but just for the form submission.
Because I'm using spring security I did a little bit resarch and I found the requires-channel="https" for the intercept-url, but I notice that the form sent first the login information in plain text and just then the connections is "converted" to https.
One other way I found was to change the action of my form to use the https link
<form id="login" action="https://localhost:8443/j_spring_security_check" method="POST" >
Everything was sent in a secure way (like I expected), the loadUserByUsername is called, everything worked as expected, but when the job was done, the user appears to be not authenticated. Looks like nothing happens...
Maybe I'm missing something or I'm not following the right pad... someone knows what I need to do or point me in the right direction?
Edit: I dig a little bit more about this subject and I start wondering if the best will be to secure the full website rather than the login or registration form. This will be an e-commerce website, so a few extra security is always welcome. My worries are about the bennefits/performance (pros and cons) that the https will have compared to http use (anyone knows??) !!
After many days of researching and testing (almost a month) I arrived to conclusion that the best approach for this problem is not use a secure connection for the form but for the entire application (in my case need to be the entire because the login form is present in all app as a popup element).
For others, the reason to change was to give the customer the assurance that the data is secure and the website is trusted (the symbol in the address link)... Also, I read somewhere is good for SEO!!
I hope with this answer I could clarify someone with the same issue as mine!!
Is there any web language that allows the client itself to create HTTP posts to external sites.
I know that JavaScript does this with XMLHttpRequest, but it does not allow cross-domain posting, unless the recipient domain wants to allow the sending domain.
I want to post data to an external site (that I don't control) and have the request be authenticated with what the client's browser already has (cookies, etc).
Is this possible? I tried cURL but it seems to make a server HTTP post, not a client HTTP post.
Edit:
A bit more insight of what I am trying to do:
I am trying to POST JSON to the website using the user's session (I said cookies but I believe they are PHP sessions, which I guess I still consider cookies).
The website does NOT check the referral (poor security #1)
I can execute javascript and html on the webpage using my personal homepage (poor security #2)
The JSON code will still work even if the content-type is form (poor security #3)
There is no security checking at all, just PHP session checking.
The form idea is wonderful and it works. The probably again is that its JSON. So having sent postdata as foo={"test":"123", "test2":"456"} the whole foo= part messes it up. Plus forms seem to turn JSON into form encoding, so its sending:
foo=%7B%22
test%22%3A+%22
123%22%2C+%22
test2%22%3A+%22
456%22%7D
when i need it to send;
{"test":"123", "test2":"456"}
So with everything known, is there a better chance of sending JSON or not?
I don't think so: You won't get hold of the user's auth cookies on the third party site from server side (because of the Single Origin Policy) and you can't make Ajax requests to the third party site.
The best you can do is probably create a <form> (maybe in an <iframe>), point it to the third party site, populate it with data, and have the user submit it (or auto-submit it). You will not be able to get hold of the request results programmatically (again because of the Single Origin Policy), but maybe it'll do - you can still show the request results to the user.
I think for obvious reasons this is not allowed. If this was allowed what would stop a malicious person from posting form data from a person's browser to any number of sites in some hidden iframe or popup window.
If this is a design of your application you need to rethink what you are trying to accomplish.
EDIT: As #Pekka was pointing out I know you can submit a form to a remote site using typical form submits. I was referring to using some client side ajax solution. Sorry for the confusion.
You should follow the way OpenID and other single-sign-on system works. How openID works is your website POSTs some token to openID service and in return gets authentication result. Refer How Does it Work? section here
Yes, you can use a special flash library that supports cross-domain calls: YUI connection manager
Added: not sure about the cookie authentication issue though...
The client cannot post to an external site directly; it's a breach of basic cross-domain security models. The exception is accessing javascript with JSONP. What you describe would require access to a user's cookies for another website, which is impossible as the browser only allows cookie access within the same domain/path.
You would need to use a server-side proxy to make cross-domain requests, but you still cannot access external cookies: http://jquery-howto.blogspot.com/2009/04/cross-domain-ajax-querying-with-jquery.html