I'm working on getting Google Identity Toolkit set up, and according to the AOL instructions, you have to place a xrds document in the site's root to avoid warnings on the user's end. I'm a little confused as to how this works. Do I simply create xrds.xml with the relevant content and place it in the root directory, or does the file need to be referenced in the site's page headers as well? Is this still applicable to Identity Toolkit V3?
Google Identity Toolkit V3 is the recommended version and the XRDS file is needed as well.
The XRDS file could be of any name on your site, and your site could
return the file name through either
1) an HTML document with a element that includes a
element with http-equiv attribute, X-XRDS-Location,
or
2) HTTP response-headers that include an X-XRDS-Location response-header
An example of #2 is your server returns http response with header
X-XRDS-Location: https://your-web-site.com/yadis.html
where the content of the yadis.html looks like
<xrds:XRDS><XRD>
<Service>
<Type>http://specs.openid.net/auth/2.0/return_to</Type>
<URI>https://your-web-site.com/gitkit</URI>
</Service>
</XRD></xrds:XRDS>
Related
Is there a way to show a custom html page or redirect a user when storage throws errors like if file is not available, not sufficient permissions or in case of any other issues when the file can't be accessed/displayed?
So instead of the below
We need to show a custom page with our brand designs.
What are the options here?
No, there is not. You are using an API endpoint (download URL) meant for programmatic consumption or inline page insertion, not for loading into a browser to present a full web page.
I want to embed external content on a website in an iframe. I can only load internal websites and external are undefined.
How can I enable CORS in Intershop 7.7 and load an external URL in an iframe or data dialog?
There is nothing special in using iframes in Intershop compared to another platform. Simply put in your ISML:
<iframe src="https://example.com">
</iframe>
Of course this may not succeed to load as you noticed. Some servers include the X-Frame-Options header with value e.g. SAMEORIGIN which instructs the browser that they don't want to be framed on other sites. This may be used to prevent clickjacking attacks. You may use Firebug or any appropriate tool to monitor for such errors during the frame load. An iframe may also not load if you mix http/s traffic.
If you want to programatically access content from an iframe on a different domain, you may use the Web Messaging API (window.postMessage and the onmessage event) to communicate between the page and the included iframe.
In summary:
you can't simply frame any site (maybe your 'internal' site permits that);
this question is not relevant for the Intershop technology stack;
This should be possible with the content security policy support since version 7.6.
Please check the documentation of appserver.properties file. The keys intershop.response.content-security-policy. should help.
When I search my problem I find this old question.
How to find out what technology a program is using?.
Its define how to show but not how to hide ? I have several asp.net sites .Some of my sites use CKEditor and others JavaScript Libraries.
when I type my url in :
http://builtwith.com/
its show :
Is there any web.config setting or another setting not to show technology or program used by my site.I search a lot but unable to find any thing.Any help would be much appreciated .Thanks.
By default ASP.NET shouts about itself a lot. It sends HTTP headers with each response telling the world and dog what version of ASP.NET your site is hosted on and even what version of MVC you are using. Below is an example of the extra headers needlessly being sent with every request:
To fix this problem you need to do a few things. The first is to set the enableVersionHeader setting on the httpRuntime section to false.
<!-- enableVersionHeader - Remove the ASP.NET version number from the response headers. Added security through obscurity. -->
<httpRuntime targetFramework="4.5" enableVersionHeader="false" />
Then you need to clear the custom headers as shown below.
<httpProtocol>
<customHeaders>
<!-- X-Powered-By - Remove the HTTP header for added security and a slight performance increase. -->
<clear />
</customHeaders>
</httpProtocol>
for more read this post: Securing the ASP.NET Web.config
And also there is project in github which called NWebsecand NWebsec lets you configure quite a few security headers, some are useful for most applications while others are a bit more specialized. Here's the project link:
Getting started with NWebsec.
In addition to obfuscating your scripts, your website may also give away information in the form of http headers and html meta tags. For example one of my sites shows these http response headers:
Server: Microsoft-IIS/8.5
X-AspNet-Version: 2.0.50727
X-Powered-By: ASP.NET
These show my site is running iis8.5 and which .net version which is the first information shown on builtwith.com. Most if not all web servers have a way of suppressing these and of course you can control the meta tags.
Also the url can contain clues as well. If you have urls that end in .aspx, .jsp, .php that is a dead giveaway. You can solve this using SEF urls or by using some sort of url rewriter for whatever server technology you are using
Please, note that there are already exact same questions about it:
StackOverflow
Nick says that if you're running apache, you can set your ServerTokens to Prod and set your ServerSignature to Off to remove the used modules from http requests. I hope you could find a similar property for your asp.net application.
Authentictech also says on behalf of gary that you can ask them to remove your sites from their lookup service on this link. Looking at that link, you (as a domain owner) can remove your sites' entries from their lookup index forever.
WebMasters
Su' says that there's a BuildWith's page that tells:
The technology has to be discoverable in either the page body, cookies
or server headers.
It also mentions Security through obscurity, but concludes that (on a security point of view) the modules' security is much more important than hiding what you're using
Assuming that you are interested on general explanations (since there might be other builtwith-like sites doing similar things):
Those kind of applications probably analyzes also hints like the html structure, the html attributes, the html meta tags, the http headers, the built url and its file extensions, and the html view state, which enables it to analyze and (given a few technology-specific patterns/standards) infer which technologies you use like asp.net, jsf, and others. So, even you could some way really obfuscate the generated script, customize the built url, and handle the http headers, I think you won't be fully able to hide the used technologies due to html structure including its attributes, meta tags and view state controls.
So I've set up an HTML5 single page application, and it's working well. The page is at /App/ and when some one goes to content it looks like /App/Content/1234.
One problem: If the user refreshes the page the server can't find that URL because it doesn't actually exist. If I send them to /App/#/Content/1234, they're golden, but what is the best way to do this? I have a LOT of different styles of URL under /App.
What is the best way to globally catch any request under ~/App/(.*) and redirect it to ~/App/#/$1?
The only route registered in MVC is the standard OOTB route.
Sounds like your server is not re-writing the urls to the app's base URL.
The URL re-writing needed on the web server is server-dependent. For Apache, you'd use mod_rewrite.
Instead, switch Angular to the "Hashbang mode" (the default) so the urls will all store the local state after the # in the url.
I don't want my apps to require server configuration changes, so I recommend hashbang mode.
See AngularJS docs. See section "Hashbang and HTML5 Modes" The HTML5 mode section describes all the configuration issues needed to support HTML5 mode for the urls.
This awesome dude describes how to fix this here.
In brief:
Remove MVC nugets (unless you use MVC controllers for anything) -
you can keep the Web API nugets. Keep WebPages and Razor packages.
Also delete MVC controllers and views.
You can keep using .cshtml
files with some web.config modifications. You'll need this for
bundling.
Finally you add a rewrite rule on web.config to point all urls (excluding content, images, scripts etc) to index.html
I am making an application with the Google Maps API. I want to be able to have one person on a computer, watch what another person has edited to a map. I am thinking of passing information of the map to a Google Fusion Table. The other person will be able to see everything as a layer. I would like for the program to just run from the user's browser and not build a website for it.
To edit the fusion tables, I need to gain access/tokens. I am currently trying to use these there JavaScript to accomplish this. ScriptSample.html, oauthWindow.html, and gwt-oauth2.js. This is the working example.
When I run them, I get am error that says the redirect URI is incorrect. It says the file I use to redirect does not have authority. My first obvious question is:
How do I give that file authority to redirect?
In my API console, I have it set up as a client-side web application. Should I change it to an installed application?
Currently I have the following settings:
my JavaScript origin is: https://localhost
redirect URI: https://localhost/oauthWindow.html
Thanks
There's no problem with using a localhost url for Dev work - obviously it needs to be changed when it comes to production.
You need to go here:
https://developers.google.com/accounts/docs/OAuth2
and then follow the link for the API Console - link's in the Basic Steps section. When you've filled out the new application form you'll be asked to provide a redirect Url. Put in the page you want to go to once access has been granted.
When forming the Google oAuth Url - you need to include the redirect url - it has to be an exact match or you'll have problems. It also needs to be UrlEncoded.