Not sure under which category my question falls. I'm in great confusion and really need some expert suggestions.
I have PHP site for E-commerce (Opencart) running on the domain- www.example.com and developed a PWA mobile website which is ready to be launched, at this point I have fallen into so many confusion.
I want to host a mobile site with subdomain m.example.com. The backend (REST API) is same for desktop and the mobile site which is hosted in example.com
when I make API calls from m.example.com to example.com preflight OPTION request is sent for each and every request which almost takes 200ms to 300ms.
There is an option to avoid OPTION requests by making the simple request, but not possible with my case as I have Token based authentication and need to token in every API call
To avoid OPTION requests, the option is to host the same REST API in m.example.com as well (just checked mobile.twitter.com API request goes to mobile.twitter.com), and both m.exampole.com and example.com sharing common Database.
This has another problem, any change in the API needs the update in both sites.
My questions are
What is the optimal way of handling this situation?
if I'm going with m.example.com - the redirection can be done at front-end level or via a .htaccess rule, which option is ideal?
Is it a good idea to host REST API in m.example.com as well?
Related
I have a logic written on my server mostly doing curl requests (e.g. accessing social networks). though, some of the sites, will be blocking my server(s) IPs soon.
I can of course, use VPN or deploy multiple servers per location, but it won't get accurate, and still some of the networks might get block the user account.
I am trying to find creative solution to run it from the user browser (it is ok to ask for his permission, as it is an action he is explicitly trying to execute) Though I am trying to avoid extra installations (e.g. downloadable plugins\extension or a desktop app)
Is there a way to turn the client browser into a server-proxy, to run those curl-calls from his machine instead of sending it from my own server? (e.g. using web-sockets, polling, etc.)
It depends on exactly what sort of curl requests you are making. In theory, you could simulate these using an XMLHttpRequest. However, for security reasons these are generally not allowed to access resources hosted on a different site. (Imagine the sort of issues it could cause for instance if visiting any website could cause your browser to start making requests to Facebook to send messages on your behalf.) Basically it will depend on the Cross-origin request policy of the social networks that you are querying. If the requests being sent are intended to be publicly available without authentication then it is possible that your system will work, otherwise it will probably be blocked.
I have a security concern about building a SPA application.
What is stopping an end user to make calls to my Web API as long as they have a token?
For example: I am an end user to a Spa web application and I login through the login form. Get access to the JWT token provided to me (assuming this is easy). Then open up postman and try making every call possible putting that token in the header of every request.
I am assuming the only calls I would be able to make are the ones I would be authorized to make through the UI due to Web API authorization.
Is there any type of security out there to prevent this or is it basically just make sure your Web API has proper authorization?
There is absolutely no difference here to regular websites/web applications. Yes, anyone can try to make any HTTP calls they wish to your server. That holds for plain websites, jQuery sites, SPA sites, mobile applications or Flash games. Your server needs to do the proper authorisation and validation to ensure the user is allowed to do what they're attempting to do.
I have a WebSite (MVC 4) and WebService (Web API). WebSite has an authentication cookie and it decrypts that in order to send a secure token on to WebService when the WebSite server side code calls the service. That works fine.
However, the WebSite has JavaScript that I would like to call the WebService directly. I've tried sharing the MachineKey and Auth information, but the cookie is not carried across the WebApi.
My fallback is to route all calls to the WebService via the WebSite; but that's ugly and slow.
Any ideas?
The correct answer is Darin's. In order to share a login cookie between a services site and a web site, they will both have to be on the same domain; so e.g. the services site could be at
http://svc.mysite.com
And the web site could be at
http://www.mysite.com
Then the browser will allow the two sites to share the same cookie.
An alternative would be to have the site authenticate to the services site and get a token of some kind it could pass to the javascript. However, unless you were running on HTTPS this would be highly insecure, as the token would be available "in the clear".
A final mechanism (and the most common solution I think) would be to route all API accesses through the web site, but this is not ideal in many circumstances.
I am writing a Phonegap application that needs to be able to call remote webservices that are secured by CAS. The application will also be hosted on our webfarm (minus the hardware specific parts) as a mobile web site.
Our CAS server is hosted by server1 and our webservices are hosted on server2. The mobile web site is hosted on server2.
Any calls I make from Javascript get a cross-domain error. I realize this isn't an issue for the phone, but it would be nice to avoid it due to development being so much easier when running on the desktop.
Currently, I have a working setup that consists of the following:
Javascript calls a server-side script on server2 over https, including the username and password in the header.
The script calls CAS' RESTful api and gets a ticket granting cookie. The script creates a Set-Cookie header in the response or it reports back with a login error.
Javascript gets the response and creates the cookie (though this cookie is undetectable in Phonegap (nothing in document.cookie), even though it's getting passed around).
Javascript then calls a server-side script which calls a webservice for it, passing the cookie with the request (I had to manually insert the cookie into the request header, even though it automatically was passed in the request from javascript).
The server-side script sends the results to javascript.
Is there a better way to do this? I've seen mention of proxy tickets in CAS, but cannot find enough information to know whether it's what I need or how to use them.
Thank you.
Suppose:
You have a website http://www.example.com that redirects to a project on Google App Engine (i.e. example.appspot.com);
you want communications to pass between the user over SSL (i.e. https://example.appspot.com); and
You want the domain to be shown to the user to be *://www.example.com (i.e. not https://example.appspot.com).
Given that Google's Appspot HTTPS support only works for https://example.appspot.com (i.e. you cannot set up https://www.example.com with GAE), I'd like to have an Ajax solution, namely:
http://www.example.com serves HTML and Javascript over http
Ajax requests go over SSL to https://example.appspot.com
My question/concern is: How does one ensure that the users logged into http://www.example.com (by way of Google's users API) pass their authentication credentials over Ajax to https://example.appspot.com?
This seems to be a violation of the same origin policy (which may or may not be a concern for the Google Users API), so how would one know what user is logged in to example.com for the Ajax requests to example.appspot.com?
Thoughts, comments and input is quite appreciated.
Thank you.
Brian
There are ways to work around same-origin when both sites cooperate, e.g. see this post, but only trial-and-error will reveal which techniques do work for your specific requirements (it may depend on how strictly the user has set security safeguards in their browser, as well as on server-side implementations).
You can try using JSONP to get around the around that. However JSONP doesnt have very good error recovery like JSON does when doing XHR calls.
Wouldn't it be far simpler to use frames? Serve up a single full-size frameset from yourdomain.com containing content from https://yourapp.appspot.com/.
Note, though, that either solution has the problem that users see an unsecured site, not a secured one.
example.appspot.com does not share any cookies with example.com - it will be impossible for you to identify the user without making them sign-in on example.appspot.com as well.
you could, of course, completely ditch Google Authentication on example.appspot.com and implement your own scheme; you could append a signature and the username to the AJAX requests you create and verify that signature on your app-engine app. if the signature is valid, just accept the user that was passed in as the authenticated user and pretend he logged in.