구글 확장프로그램 만들기 목표

일명 구글해킹이라고 불리는 intext: inurl: 등등을 일반 사용자도 쉽게 사용할 수 있는 환경 제공

구글 검색 해킹 

-->

googledork(구글 해킹).pdf

위와 같은 형태로 제작할 예정

https://developer.chrome.com/extensions/samples

제작 완료

출처:https://developer.chrome.com/extensions/overview

Overview

Once you've finished this page and the Getting Started tutorial, you'll be all set to start writing extensions.

The basics

An extension is a zipped bundle of files—HTML, CSS, JavaScript, images, and anything else you need—that adds functionality to the Google Chrome browser. Extensions are essentially web pages, and they can use all the APIs that the browser provides to web pages, from XMLHttpRequest to JSON to HTML5.

Extensions can interact with web pages or servers using content scripts orcross-origin XMLHttpRequests. Extensions can also interact programmatically with browser features such asbookmarks and tabs.

Extension UIs

Many extensions—but not Chrome Apps—add UI to Google Chrome in the form of browser actions or page actions. Each extension can have at most one browser action or page action. Choose a browser action when the extension is relevant to most pages. Choose a page action when the extension's icon should be active or inactive (and grayed out), depending on the page.

This Google Mail Checker extension uses a browser action.	This Mappy extension uses apage action and content script (code injected into a web page).	This Set Page Color extensionfeatures a browser action that, when clicked, shows a popup.

Extensions (and Chrome Apps) can also present a UI in other ways, such as adding to the Chrome context menu, providing an options page, or using a content script that changes how pages look. See the Developer's Guide for a complete list of extension features, with links to implementation details for each one.

Files

Each extension has the following files:

• A manifest file
• One or more HTML files (unless the extension is a theme)
• Optional: One or more JavaScript files
• Optional: Any other files your extension needs—for example, image files

While you're working on your extension, you put all these files into a single folder. When you distribute your extension, the contents of the folder are packaged into a special ZIP file that has a .crx suffix. If you upload your extension using the Chrome Developer Dashboard, the .crx file is created for you. For details on distributing extensions, see Hosting.

Referring to files

You can put any file you like into an extension, but how do you use it? Usually, you can refer to the file using a relative URL, just as you would in an ordinary HTML page. Here's an example of referring to a file namedmyimage.png that's in a subfolder named images.

<img src="images/myimage.png">

As you might notice while you use the Google Chrome debugger, every file in an extension is also accessible by an absolute URL like this:

chrome-extension://<extensionID>/<pathToFile>

In that URL, the <extensionID> is a unique identifier that the extension system generates for each extension. You can see the IDs for all your loaded extensions by going to the URL chrome://extensions. The <pathToFile>is the location of the file under the extension's top folder; it's the same as the relative URL.

While you're working on an extension (before it's packaged), the extension ID can change. Specifically, the ID of an unpacked extension will change if you load the extension from a different directory; the ID will change again when you package the extension. If your extension's code needs to specify the full path to a file within the extension, you can use the @@extension_id predefined message to avoid hardcoding the ID during development.

When you package an extension (typically, by uploading it with the dashboard), the extension gets a permanent ID, which remains the same even after you update the extension. Once the extension ID is permanent, you can change all occurrences of @@extension_id to use the real ID.

The manifest file

The manifest file, called manifest.json, gives information about the extension, such as the most important files and the capabilities that the extension might use. Here's a typical manifest file for a browser action that uses information from google.com:

{
  "name": "My Extension",
  "version": "2.1",
  "description": "Gets information from Google.",
  "icons": { "128": "icon_128.png" },
  "background": {
    "persistent": false,
    "scripts": ["bg.js"]
  },
  "permissions": ["http://*.google.com/", "https://*.google.com/"],
  "browser_action": {
    "default_title": "",
    "default_icon": "icon_19.png",
    "default_popup": "popup.html"
  }
}

For details, see Manifest Files.

Architecture

Many extensions have a background page, an invisible page that holds the main logic of the extension. An extension can also contain other pages that present the extension's UI. If an extension needs to interact with web pages that the user loads (as opposed to pages that are included in the extension), then the extension must use a content script.

The background page

Background pages defined by background.html can include JavaScript code that controls the behavior of the extension. There are two types of background pages: persistent background pages, and event pages. Persistent background pages, as the name suggests, are always open. Event pages are opened and closed as needed. Unless you absolutely need your background page to run all the time, prefer to use an event page.

See Event Pages and Background Pages for more details.

UI pages

Extensions can contain ordinary HTML pages that display the extension's UI. For example, a browser action can have a popup, which is implemented by an HTML file. Any extension can have an options page, which lets users customize how the extension works. Another type of special page is the override page. And finally, you can usetabs.create or window.open() to display any other HTML files that are in the extension.

The HTML pages inside an extension have complete access to each other's DOMs, and they can invoke functions on each other.

The following figure shows the architecture of a browser action's popup. The popup's contents are a web page defined by an HTML file (popup.html). This extension also happens to have a background page (background.html). The popup doesn't need to duplicate code that's in the background page because the popup can invoke functions on the background page.

See Browser Actions, Options, Override Pages, and the Communication between pages section for more details.

Content scripts

If your extension needs to interact with web pages, then it needs a content script. A content script is some JavaScript that executes in the context of a page that's been loaded into the browser. Think of a content script as part of that loaded page, not as part of the extension it was packaged with (its parent extension).

Content scripts can read details of the web pages the browser visits, and they can make changes to the pages. In the following figure, the content script can read and modify the DOM for the displayed web page. It cannot, however, modify the DOM of its parent extension's background page.

Content scripts aren't completely cut off from their parent extensions. A content script can exchange messages with its parent extension, as the arrows in the following figure show. For example, a content script might send a message whenever it finds an RSS feed in a browser page. Or a background page might send a message asking a content script to change the appearance of its browser page.

For more information, see Content Scripts.

Using the chrome.* APIs

In addition to having access to all the APIs that web pages and apps can use, extensions can also use Chrome-only APIs (often called chrome.* APIs) that allow tight integration with the browser. For example, any extension or web app can use the standard window.open() method to open a URL. But if you want to specify which window that URL should be displayed in, your extension can use the Chrome-only tabs.create method instead.

Asynchronous vs. synchronous methods

Most methods in the chrome.* APIs are asynchronous: they return immediately, without waiting for the operation to finish. If you need to know the outcome of that operation, then you pass a callback function into the method. That callback is executed later (potentially much later), sometime after the method returns. Here's an example of the signature for an asynchronous method:

chrome.tabs.create(object createProperties, function callback)

Other chrome.* methods are synchronous. Synchronous methods never have a callback because they don't return until they've completed all their work. Often, synchronous methods have a return type. Consider theruntime.getURL method:

string chrome.runtime.getURL()

This method has no callback and a return type of string because it synchronously returns the URL and performs no other, asynchronous work.

Example: Using a callback

Say you want to navigate the user's currently selected tab to a new URL. To do this, you need to get the current tab's ID (using tabs.query) and then make that tab go to the new URL (using tabs.update).

If query() were synchronous, you might write code like this:

//THIS CODE DOESN'T WORK
var tab = chrome.tabs.query({'active': true}); //WRONG!!!
chrome.tabs.update(tab.id, {url:newUrl});
someOtherFunction();

That approach fails because query() is asynchronous. It returns without waiting for its work to complete, and it doesn't even return a value (although some asynchronous methods do). You can tell that query() is asynchronous by the callback parameter in its signature:

chrome.tabs.query(object queryInfo, function callback)

To fix the preceding code, you must use that callback parameter. The following code shows how to define a callback function that gets the results from query() (as a parameter named tab) and calls update().

//THIS CODE WORKS
chrome.tabs.query({'active': true}, function(tabs) {
  chrome.tabs.update(tabs[0].id, {url: newUrl});
});
someOtherFunction();

In this example, the lines are executed in the following order: 1, 4, 2. The callback function specified to query()is called (and line 2 executed) only after information about the currently selected tab is available, which is sometime after query() returns. Although update() is asynchronous, this example doesn't use its callback parameter, since we don't do anything about the results of the update.

More details

For more information, see the chrome.* API docs and watch this video:

Communication between pages

The HTML pages within an extension often need to communicate. Because all of an extension's pages execute in same process on the same thread, the pages can make direct function calls to each other.

To find pages in the extension, use chrome.extension methods such as getViews() andgetBackgroundPage(). Once a page has a reference to other pages within the extension, the first page can invoke functions on the other pages, and it can manipulate their DOMs.

Saving data and incognito mode

Extensions can save data using the storage API, the HTML5 web storage API (such as localStorage) or by making server requests that result in saving data. Whenever you want to save something, first consider whether it's from a window that's in incognito mode. By default, extensions don't run in incognito windows. You need to consider what a user expects from your extension when the browser is incognito.

Incognito mode promises that the window will leave no tracks. When dealing with data from incognito windows, do your best to honor this promise. For example, if your extension normally saves browsing history to the cloud, don't save history from incognito windows. On the other hand, you can store your extension's settings from any window, incognito or not.

Rule of thumb: If a piece of data might show where a user has been on the web or what the user has done, don't store it if it's from an incognito window.

To detect whether a window is in incognito mode, check the incognito property of the relevant tabs.Tab orwindows.Window object. For example:

function saveTabData(tab, data) {
  if (tab.incognito) {
    chrome.runtime.getBackgroundPage(function(bgPage) {
      bgPage[tab.url] = data;      // Persist data ONLY in memory
    });
  } else {
    localStorage[tab.url] = data;  // OK to store data
  }
}

Now what?

Now that you've been introduced to extensions, you should be ready to write your own. Here are some ideas for where to go next:

• Tutorial: Getting Started
• Tutorial: Debugging
• Developer's Guide
• Samples
• Videos, such as Extension Message Passing

출처:https://developer.chrome.com/extensions/getstarted

아래 내용 그대로 따라가면 됨

간단하게 

다음 4개의 구성파일이 있으면 된다.

이후  chrome://extensions에 들어가서 우측상단에 개발자 모드 체크 후 압축해제된 확장 프로그램 로드를 눌러주면된다.

튜토리얼을 완성하였다면 https://developer.chrome.com/extensions/devguide 를 참고하고 개발을 진행하면 된다.

------------- 영문 튜토리얼 -------------------

Extensions allow you to add functionality to Chrome without diving deeply into native code. You can create new extensions for Chrome with those core technologies that you're already familiar with from web development: HTML, CSS, and JavaScript. If you've ever built a web page, you should feel right at home with extensions pretty quickly; we'll put that to the test right now by walking through the construction of a simple extension that will fetch an image from Google using the current page's URL as a search term.

We'll do so by implementing a UI element we call a browser action, which allows us to place a clickable icon right next to Chrome's Omnibox for easy access. Clicking that icon will open a popup window filled with an image derived from the current page, which will look something like this:

If you'd like to follow along at home (and you should!), create a shiny new directory on your computer, and pop open your favourite text editor. Let's get going!

Something to Declare

The very first thing we'll need to create is a manifest file named manifest.json. This manifest is nothing more than a metadata file in JSON format that contains properties like your extension's name, description, version number and so on. At a high level, we will use it to declare to Chrome what the extension is going to do, and what permissions it requires in order to do those things. To learn more about the manifest, read the Manifest File Format documentation.

In our example's manifest, we will declare a browser action, the activeTab permission to see the URL of the current tab, and the host permission to access the external Google Image search API.

{
  "manifest_version": 2,

  "name": "Getting started example",
  "description": "This extension shows a Google Image search result for the current page",
  "version": "1.0",

  "browser_action": {
    "default_icon": "icon.png",
    "default_popup": "popup.html"
  },
  "permissions": [
    "activeTab",
    "https://ajax.googleapis.com/"
  ]
}

Go ahead and save that data to a file named manifest.json in the directory you created, or download a copy of manifest.json from our sample repository .

Resources

You probably noticed that manifest.json pointed at two resource files when defining the browser action:icon.png and popup.html. Both resources must exist inside the extension package, so let's create them now:

• icon.png will be displayed next to the Omnibox, waiting for user interaction.Download a copy of icon.png from our sample repository , and save it into the directory you're working in. You could also create your own if you're so inclined; it's just a 19px-square PNG file.

• popup.html will be rendered inside the popup window that's created in response to a user's click on the browser action. It's a standard HTML file, just like you're used to from web development, giving you more or less free reign over what the popup displays. Download a copy of popup.html from our sample repository , and save it into the directory you're working in.

  The actual logic of rendering the content of the popup is implemented by popup.js. You are encouraged to read the elaborate comments in this file to learn more about the logic.
  Download a copy of popup.js from our sample repository , and save it into the directory you're working in.

You should now have four files in your working directory: icon.png, manifest.json, popup.html,popup.js. The next step is to load those files into Chrome.

Load the extension

Extensions that you download from the Chrome Web Store are packaged up as .crx files, which is great for distribution, but not so great for development. Recognizing this, Chrome gives you a quick way of loading up your working directory for testing. Let's do that now.

1. Visit chrome://extensions in your browser (or open up the Chrome menu by clicking the icon to the far right of the Omnibox:  and select Extensions under the Tools menu to get to the same place).

2. Ensure that the Developer mode checkbox in the top right-hand corner is checked.

3. Click Load unpacked extension… to pop up a file-selection dialog.

4. Navigate to the directory in which your extension files live, and select it.

Alternatively, you can drag and drop the directory where your extension files live onto chrome://extensionsin your browser to load it.

If the extension is valid, it'll be loaded up and active right away! If it's invalid, an error message will be displayed at the top of the page. Correct the error, and try again.

Fiddle with Code

Now that you've got your first extension up and running, let's fiddle with things so that you have an idea what your development process might look like. For example, let's set a tooltip on the browser action button.

According to the browserAction documentation, tooltips can be set by specifying the default_title key in the manifest file. Open manifest.json, and add the default_title key to the browser_action. Make sure that the JSON is valid, so quote the key and add a comma where necessary.

{
  ...
  "browser_action": {
    "default_icon": "icon.png",
    "default_popup": "popup.html",
    "default_title": "Click here!"
  },
  ...
}

The manifest file is only parsed when the extension is loaded. If you want to see the previous changes in action, the extension has to be reloaded. Visit the extensions page (go to chrome://extensions, or Tools > Extensionsunder the Chrome menu), and click Reload under your extension. All extensions are also reloaded when the extensions page is reloaded, e.g. after hitting F5 or Ctrl-R.

Once you've reloaded the extension, hover over the browser action badge to see the new tooltip!
 

What next?

You now know about the manifest file's central role in bringing things together, and you've mastered the basics of declaring a browser action. That's a great start, and has hopefully gotten you interested enough to explore further. There's a lot more out there to play around with.

• The Chrome Extension Overview backs up a bit, and fills in a lot of detail about extensions' architecture in general, and some specific concepts you'll want to be familiar with going forward. It's the best next step on your journey towards extension mastery.

• No one writes perfect code on the first try, which means that you'll need to learn about the options available for debugging your creations. Our debugging tutorial is perfect for that, and is well worth carefully reading.

• Chrome extensions have access to powerful APIs above and beyond what's available on the open web: browser actions are just the tip of the iceberg. Our chrome.* APIs documentation will walk you through each API in turn.

• Finally, the developer's guide has dozens of additional links to pieces of documentation you might be interested in.

출처:http://egs41.tistory.com/entry/%ED%94%BC%EB%93%A4%EB%9F%AC%EB%A1%9C-%ED%95%A0-%EC%88%98-%EC%9E%88%EB%8A%94-%EC%9D%BC-%EC%97%86%EB%8A%94-%EC%9D%BC

▶ 피들러로 할 수 있는 일

  ⊙ 브라우저, 클라이언트 프로그램, 서비스 등에서 오고 가는 웹 트래픽을 볼 수 있다.

  ⊙ 자동 또는 수동적인 방법으로 어떠한 응답이나 요청도 수정할 수 있다.

  ⊙ HTTPS 트래픽을 복호화하여 살펴보거나 수정하는 것도 가능하다.

  ⊙ 캡쳐한 트래픽을 저장하여 보관해 두고 나중에 불러올 수도 있다. 다른 컴퓨터의 트래픽도 이런 식으로 다룰 수 있다.

  ⊙ 클라이언트 프로그램으로 가는 응답을 이전에 캡쳐해 두었다면 서버가 오프라인 상태라 해도 응답을 재현할 수 있다.

  ⊙ 맥/리눅스 시스템, 스마트폰, 태블릿 컴퓨터 등을 포함한 대부분의 PC와 모바일 기기에서 발생한 웹 트래픽을 디버깅할 수 있다.

  ⊙ TOR 네트워크 등 프록시 서버에 업스트림(upstream)을 연결(chain)할 수 있다.

  ⊙ 클라이언트 컴퓨터나 모바일 기기를 다시 설정하지 않고도 역 프록시(reverse proxy)로 동작하여 트래픽을 캡쳐할 수 있다.

  ⊙ 피들러 스크립트나 .NET 기반 확장 모듈을 통해 새로운 기능을 추가할 수 있어 더 강력해질 수 있다.

▶ 피들러로 할 수 없는 일

  ⊙ 웹 프로토콜 트래픽이 아닌 경우에는 디버깅할 수 없다.

    → 피들러는 HTTP, HTTPS, FTP 트래픽 그리고 HTML5 웹소켓(Web-Socket)이나 ICY 스트림과 같은 관련 프로토콜에 대해서만 작동한다.

    → 피들러는 SMTP, POP3, 텔넷, IRC 등의 다른 프로토콜의 트래픽은 볼 수 없다.

  ⊙ 너무 큰 요청이나 응답은 다룰 수 없다.

    → 피들러는 크기가 2기가바이트 이상인 요청은 다루지 못한다.

    → 피들러는 크기가 2기가바이트 이하의 응답만 다룰 수 있다.

    → 피들러는 시스템의 메모리와 페이지 파일을 사용하여 세션 데이터를 저장한다. 목록에 저장한 세션 수가 너무 많거나 요청이나 응답이 너무 크면 성능이 저하될 수 있다.

  ⊙ "마법처럼" 웹 사이트에 있는 버그를 없애지는 못한다.