hello all i havent managed to find this elsewhere here nor in the old GAS product forum so here goes:
i am writing a simple client javascript which queries various APIs. when it comes to querying a certain GAS script i have set up to access gmail, i understand i am supposed to serve its data through JSONP. the client script dynamically injects a SCRIPT tag and should normally handle this "response" as script. except whenever the response contains html, requesting the user to grant permissions. in this case this HTML goes into the SCRIPT raising syntax error with MIME type mismatch.
researching this problem i was led to believe the solution lies somewhere around redirecting the user to this page always before every call. so my question is, where can i find best practice regarding this issue?
Unfortunately there isn't a full solution for detecting and granting authorizations to scripts used in JSONP requests. I've seen workarounds where an application first prompts the users to visit the web app's URL, so that they can grant authorization, before allowing them to use the JSONP portion of the application.
Related
The company I work for has an web application built with Angular, that has user authentication.
We also have a blog built with Webflow for simplicity.
The thing is, we want to create special pages on our blog only for premium users. For that, a user would need to sign in on the blog (webflow) using the same account they use on the main web application. After that, the blog would also need to know if they should have access to said pages (is a premium user), and then allow them to access such areas.
I've been looking for information about this, but I've been unable to locate a clear answer. I tried following this, but the GET request for https://webflow.com/oauth/authorize (using my own clientID) returns their home page. This can be seen on the printscreen below:
The request has the following format: https://webflow.com/oauth/authorize/?client_id=<CLIENT_ID>&response_type=code. It redirects twice (code 301 and 302), then just returns me their homepage.
In fact, I'm not even sure this oauth integration would solve my problem. Is this even achievable using webflow?
So I've been going through my forms recently to check my SQL queries are secure along with sanitizing any input and have just found that entering <? into a text box triggers a 403 before it even hits the processing file, I can only assume it must be related to mod_security??
My question is, is this something to just not worry about if it's controlled by the web host as I'm using shared hosting.
I recently ran into a problem with submitting form data via a GET request to the server after using jQuery's .serialize() function for the submitted variables. These were web apps that had worked flawlessly for years. It turned out that after a recent ModSecurity rule set update, I was triggering the 211700 (HTTP redirect) and 217280 (smuggling attack) rules in Comodo's WAF ruleset, which the server uses with ModSecurity. I wasn't getting a 403. My IP address got blocked by the firewall. :(
The fix was switching my AJAX code to use to POST instead of GET, and not using .serialize(). I still have some web apps that use .serialize() and GET requests via AJAX without triggering ModSecurity, so I believe it is also necessary to pass suspect characters, as you discovered, though in my testing, all I was using was parentheses.
Since you're on a shared server, it's probably not possible--or worth your time--to find out what rule set the host is using, so your best bet is most likely to switch your form submissions to using POST instead of GET, and not use .serialize(). I figure those rules are there for a reason, and a better approach is to avoid having my code look like it's doing something nefarious than to disable the rules.
I'm a new to RESTful API's and sort of developing my first one at the moment for a mobile application to be followed. I have a question regarding API versions and how to manage/tackle them.
At this moment, my API 'version' is a directory named v<version_name> in which my API class resides. In that directory, I have resources that the API and REST client needs in another directory named include. So the structure is as follows: example.com/api/v0.2/method_name/ and on .htaccess, I'm making sure that everything that follows the API version (hardcoded in the .htaccess file, is saved in a query string parameter).
I'm not sure if it is the right approach for a live application as it requires manually changing the URL endpoints at clients' ends, too. So my questions are:
Is this the right approach to API versioning?
If it is and I keep it, how do I deal with outdated URL's. Say for instance the app is live and I update the API to v0.3 but the client who have the app installed would be accessing v0.2 and getting a 404 response code back?
Is there more elegant solution out there? It must be.
Edit: there are some resources that reside outside of the api folder itself, in the root include folder so to speak.
Edit 2: My API is targeted to be consumed by mobile applications and is not publicly consumable.
While I think these questions are primarily opinion-based, I will have a go...
I think it is a valid approach, and I've seen others use it,
including Microsoft.
When it is necessary to outdate an API, you could give a 404
back with an explanation that the new API is at the new address.
HOWEVER it is usually a bad idea to just retire an API version; you
would at least have to give client developers enough time to switch
to the new API before retiring the old, if at all.
A more elegant solution would be to just keep the API at one
address, and update that as necessary, and add to it rather than
replace whenever possible. Keep supporting outdated functions for as
long as possible and have open communication to client developers
about when a certain method will no longer work.
Just my opinion, do with it what you will...
Currently Azure Websites don't allow custom SSL certificates, but they have wildcard SSL enabled for the *.azurewebsites.net domain. I need a secure login form for my web app, but with no custom SSL, it appears that I'm SOL.
Is there any kind of workaround for this? Would it be possible somehow to have a login form at https://mydomain.azurewebsites.net that creates a forms authentication ticket that will then work at http://mydomain.com?
Couple of months ago I had exactly the same problem i.e. application was built on Azure Websites, had to run on custom domain other than *.azurewebsites.net and had to allow secure login process.
Workaround for that we used was to embed an iframe (using secure protocol and .azurewebsites.net domain name e.g. https://oursite.azurewebsites.net/login) into non-secure page on custom domain (e.g. http://mysite.com/login). And entire login process was performed in the iframe.
There is one thing which you should be aware of, namely, lots of customers checks whether the page where they provide their credentials was using secure connection or not. In our case, secure iframe in non-secure page was causing lots of customer complains. Workaround for that problem was to put a message confirming that the login process uses secure connection. The message made some improvements, however, still certain number of customers complains remained.
I hope that will help.
This isn't really an answer to your question, but Microsoft are very aware that custom mapped SSL to websites is one of the most requested features for Azure websites and they have said they are working on it.
Scott Hanselman himself confirms it here
In the meantime, Tom's answer is a perfectly valid workaround.
One thing I would be very wary of though is with something Tom brings up: the security warning that the browser will present. You'd be amazed how many people freak out when they see that message and don't go any further! We have a fairly active ecommerce site and there have been occasions where we have accidentally used a none secure image path on an SSL page and we have always received emails from customers asking if our site has been hacked or similar!
The disclaimer that Tom mentions is a good idea, but I think it will still put some people off.
I am working directly with the WAWS team right now to produce some public guidance for this. A GitHub repository with the requirements is currently being evaluated by the team (I sent it over to them literally 1 hour ago). Hopefully, the solution will be approved and made public within a few weeks.
I can say this - the workaround won't be fully supported or much custom guidance given on its usage aside from the repository and accompanying documentation. SSL is, literally, the #1 priority for the product, and hundreds of people are working insane hours to make it happen for everyone. This workaround should also be considered temporary, as you'll no longer need it once the full SSL functionality is launched.
I have a web application written in PHP. The templating engine is SMARTY. My question is very simple, yet the answer should not be that easy, because I searched the hell out of it to no avail.
When I telnet to port 80 and run the following command:
GET /some_directory_on_my_server/?""><SCRIPT>alert(123)</SCRIPT>
The servers responds back with an html page. When I save this HTML page and open it in a browser I see alert(123) on top of the page, which means that the site is vulnerable to Cross-Site Scripting (XSS).
My question is how can I access the actual url entered by the user in order to sanitize it? When it comes to user input sanitization for forms or database queries, the scenario seems to be much easier, because you actually have a variable on hand to manipulate, but in the case of actual url entered by the user in a browser, how can I get hold of the url itself to sanitize it?
For your information, I have already read all modules which provide library functions for XSS Prevention, but none gives me an example on how to deal with actual url XSS Attack. By the way, my magic_quote_gpc in my php configuration is already turned off. What should I do now? Any thoughts?