Limiting Access with SFTP Jails on Debian and Ubuntu

 

Limiting Access with SFTP Jails on Debian and Ubuntu

Published: Wednesday, January 6th, 2010 by Phil Paradis

Linux system administrators frequently wish to give users the ability to upload files to remote servers. The most common way of doing so in a secure manner is to permit file transfers via SFTP, which uses SSH to provide encryption. By default, users are able to view the contents of the entire remote filesystem, which may not be desirable. This guide will help you configure OpenSSH to restrict users to their home directories. Please note that these instructions are not intended to support shell logins; any user accounts modified in accordance with this guide will have the ability to transfer files, but not the ability to log into a remote shell session.

Please note that these instructions will work on Ubuntu 9.04 and greater or Debian 5 and greater systems. Unfortunately, the version of SSH packaged with Ubuntu 8.04 is too old to support this configuration.

Contents

Configure OpenSSH

Edit your /etc/ssh/sshd_config file, making sure the following line is present. If your system’s file has a line that begins with "Subsystem sftp" modify it to resemble the following:

File excerpt:/etc/ssh/sshd_config

Subsystem sftp internal-sftp

Continue to add the following block to the end of the file:

File excerpt:/etc/ssh/sshd_config

Match group filetransfer
    ChrootDirectory %h
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp

Restart OpenSSH as follows:

/etc/init.d/ssh restart

Modify User Accounts

Create a group for the users who will only have SFTP access:

addgroup filetransfer

Next, you’ll need to modify the user accounts that you wish to restrict to using only SFTP. Issue the following commands for each account, substituting the appropriate username. Please keep in mind that this will prevent these users from being able to log into a remote shell session. If you don’t want to restrict your existing users, you may add new user accounts for file transfer purposes using the adduser command.

usermod -G filetransfer username
chown root:root /home/username
chmod 755 /home/username

After issuing these commands, the affected users won’t be able to create files in their home directories as these directories will be owned by the root user. You’ll want to create a set of directories for each user that they have full access to. Issue the following command for each user, changing the directories created to suit your needs:

cd /home/username
mkdir docs public_html
chown username:username *

Your users should now be able to log into their accounts via SFTP and transfer files to and from the directories located beneath their home directories, but they shouldn’t be able to see the rest of the server’s filesystem.

More Information

You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

使普通用户仅使用SFTP而没有使用Shell的权限

使普通用户仅使用SFTP而没有使用Shell的权限

  默认情况下管理员给系统添加的账号将同时具有SFTP和SSH的权限。让普通用户使用shell执行命令也是有很大的安全隐患的,如果能够禁止用户使用shell执行命令而仅使用SFTP传输文件,就能消除这种安全隐患,完全实现FTP的功能,

  正如上文所述,SFTP没有单独的守护进程,只能借助于sshd守护进程,所以我们仍然需要使用SSH服务器,要保证sshd守护进程处于运行状态。具体实现方法如下:

  首先,在编译安装时,编译中一定要有“–enable-static” 选项。安装成功后,在安装目录下的bin目录中执行下面的命令:

  [root@localhost bin]# ls -l ssh-dummy-shell* sftp-server2*

  将看到下列输出内容:

  -rwxr-xr-x 1 root root 1350417 Apr 28 16:30 sftp-server2

  -rwxr-xr-x 1 root root 3566890 Apr 28 16:30 sftp-server2.static

  -rwxr-xr-x 1 root root 72388 Apr 28 16:30 ssh-dummy-shell

  -rwxr-xr-x 1 root root 1813412 Apr 28 16:30 ssh-dummy-shell.static

  其中带“static”后缀名,且比较大的两个文件就是加上“–enable-static”选项后生成的,后面我们将用到这里两个文件。

  下面以添加普通账号test为例讲述具体操作步骤。

  1.在“/home”目录(或者将要存放普通用户宿主目录的目录)下创建“bin”子目录,并将两个static文件复制到此目录下(复制后改名去掉static后缀),执行如下命令:

  [root@localhost bin]# cd /usr/local/ssh3.2/bin

  [root@localhost bin]#cp ssh-dummy-shell.static /home/bin/ssh-dummy-shell

  [root@localhost bin]# cp sftp-server2.static /home/bin/sftp-server

  [root@localhost bin]#chown -R root.root /home/bin

  [root@localhost bin]#chmod -R 755 /home/bin

  2.添加一个组,使以后所有禁止使用shell的用户都属于这个组,这样便于管理更多的用户:

  [root@localhost bin]#groupadd template

  3.在添加系统账号时使用如下命令:

  [root@localhost root]#useradd -s /bin/ssh-dummy-shell -g template test

  [root@localhost root]#passwd test

  [root@localhost root]#mkdir /home/test/bin

  [root@localhost root]#cd /home/test/bin

  [root@localhost bin]#ln /home/bin/ssh-dummy-shell ssh-dummy-shell

  [root@localhost bin]#ln /home/bin/sftp-server sftp-server

  [root@localhost bin]#chown -R root.root /home/test/bin

  [root@localhost bin]#chmod -R 755 /home/test/bin

  3.用户添加成功后,还需要修改/etc/ssh2/sshd2_config文件,将下列内容:

  #ChRootGroups sftp,guest

  改为:

  ChRootGroups sftp,guest,template

  修改上面这行内容,主要是为了禁止普通用户查看系统的其它目录,把其权限限制在自己的主目录下。重新启动SSH服务器程序,在客户端使用SSH Secure File Transfer Client登录,即使选择显示根目录,普通用户也看不到其它的任何目录,而是把自己的主目录当作根目录。注意,这里使用的是按用户所属组限制,这样可以使包含在template组内的所有用户都可以实现此功能。若您只要限制个别用户的话,可以修改下面的内容:

  #ChRootUsers anonymous,ftp,guest

How to solve symbol conflict in Objective-C « JongAm’s blog

«

»

21
Jan

How to solve symbol conflict in Objective-C

Posted January 21, 2010 by jongampark in Objective-C, Programming. Tagged: , . 1 Comment

In Objective-C, you usually prefix your class with your initial.
For example, I would declare my Box class like JABox.
Because it becomes 2nd nature to Mac programmers, we usually don’t have symbol conflict problem.

However, if you are really really unlucky, you can use two separated 3rd party libraries or framework with same class name, structure, and so on. Unlike C++, Objective-C doesn’t provide namespace.
( Personally I don’t see usefulness of namespace in Objective-C. Philosophy is different between C++ and Objective-C. C++ is like “all the tools you need to have”, while Objective-C is “not to introduce more complexity than necessary. Make things simple. If it is not essential, don’t add any facility to Objective-C.” )

However, if you really really really need to solve symbol conflict, what should you do?

Today I found some explanation on the subject.

The point is to use @compatibility_alias. Loading each framework dynamically and unloading can’t be applied to any library and very un-handy.

Rate this:

 

 

 

 

 

 

Rate This

Share this:

Like this:

Like

Be the first to like this post.

Google Objective-C Style Guide

Google Objective-C Style Guide

Revision 2.36

Mike Pinkerton
Greg Miller
Dave MacLachlan

Each style point has a summary for which additional information is available
by toggling the accompanying arrow button that looks this way:
.
You may toggle all summaries with the big arrow button:


Toggle all summaries

Table of Contents

Important Note

Displaying Hidden Details in this Guide

This style guide contains many details that are initially
hidden from view. They are marked by the triangle icon, which you
see here on your left. Click it now.
You should see "Hooray" appear below.

Background

Objective-C is a very dynamic, object-oriented extension of C. It’s
designed to be easy to use and read, while enabling sophisticated
object-oriented design. It is the primary development language for new
applications on Mac OS X and the iPhone.

Cocoa is one of the main application frameworks on Mac OS X. It is a
collection of Objective-C classes that provide for rapid development of
full-featured Mac OS X applications.

Apple has already written a very good, and widely accepted, coding guide
for Objective-C. Google has also written a similar guide for C++. This
Objective-C guide aims to be a very natural combination of Apple’s and
Google’s general recommendations. So, before reading this guide, please make
sure you’ve read:

Note that all things that are banned in Google’s C++ guide are also
banned in Objective-C++, unless explicitly noted in this document.

The purpose of this document is to describe the Objective-C (and
Objective-C++) coding guidelines and practices that should be used for all
Mac OS X code. Many of these guidelines have evolved and been proven over
time on other projects and teams.

Open-source projects developed by Google
conform to the requirements in this guide.

Google has already released open-source code that conforms to these
guidelines as part of the

Google Toolbox for Mac project

(abbreviated GTM throughout this document).
Code meant to be shared across different projects is a good candidate to
be included in this repository.

Note that this guide is not an Objective-C tutorial. We assume that the
reader is familiar with the language. If you are new to Objective-C or
need a refresher, please read

The Objective-C Programming Language
.

Example

They say an example is worth a thousand words so let’s start off with an
example that should give you a feel for the style, spacing, naming, etc.

An example header file, demonstrating the correct commenting and spacing
for an @interface declaration

//  Foo.h
//  AwesomeProject
//
//  Created by Greg Miller on 6/13/08.
//  Copyright 2008 Google, Inc. All rights reserved.
//

#import <Foundation/Foundation.h>

// A sample class demonstrating good Objective-C style. All interfaces,
// categories, and protocols (read: all top-level declarations in a header)
// MUST be commented. Comments must also be adjacent to the object they're
// documenting.
//
// (no blank line between this comment and the interface)
@interface Foo : NSObject {
 @private
  NSString *bar_;
  NSString *bam_;
}

// Returns an autoreleased instance of Foo. See -initWithBar: for details
// about |bar|.
+ (id)fooWithBar:(NSString *)bar;

// Designated initializer. |bar| is a thing that represents a thing that
// does a thing.
- (id)initWithBar:(NSString *)bar;

// Gets and sets |bar_|.
- (NSString *)bar;
- (void)setBar:(NSString *)bar;

// Does some work with |blah| and returns YES if the work was completed
// successfully, and NO otherwise.
- (BOOL)doWorkWithBlah:(NSString *)blah;

@end

An example source file, demonstrating the correct commenting and spacing
for the @implementation of an interface. It also includes the
reference implementations for important methods like getters and setters,
init, and dealloc.

//
//  Foo.m
//  AwesomeProject
//
//  Created by Greg Miller on 6/13/08.
//  Copyright 2008 Google, Inc. All rights reserved.
//

#import "Foo.h"


@implementation Foo

+ (id)fooWithBar:(NSString *)bar {
  return [[[self alloc] initWithBar:bar] autorelease];
}

// Must always override super's designated initializer.
- (id)init {
  return [self initWithBar:nil];
}

- (id)initWithBar:(NSString *)bar {
  if ((self = [super init])) {
    bar_ = [bar copy];
    bam_ = [[NSString alloc] initWithFormat:@"hi %d", 3];
  }
  return self;
}

- (void)dealloc {
  [bar_ release];
  [bam_ release];
  [super dealloc];
}

- (NSString *)bar {
  return bar_;
}

- (void)setBar:(NSString *)bar {
  [bar_ autorelease];
  bar_ = [bar copy];
}

- (BOOL)doWorkWithBlah:(NSString *)blah {
  // ...
  return NO;
}

@end

Blank lines before and after @interface,
@implementation, and @end are optional. If your
@interface declares instance variables, a blank
line should come after the closing brace (}).

Unless an interface or implementation is very short, such as when declaring
a handful of private methods or a bridge class, adding blank lines usually
helps readability.

Spacing And Formatting

Spaces vs. Tabs

Use only spaces, and indent 2 spaces at a time.

Line Length

Each line of text in your code should try to be at most 80 characters
long.

Method Declarations and Definitions

One space should be used between the - or +
and the return type, and no spacing in the parameter list except between
parameters.

Method Invocations

Method invocations should be formatted much like method declarations.
When there’s a choice of formatting styles, follow the convention
already used in a given source file.

@public and @private

The @public and @private access modifiers
should be indented by 1 space.

Exceptions

Format exceptions with each @ label on its own line and a
space between the @ label and the opening brace
({), as well as between the @catch and the
caught object declaration.

Protocols

There should not be a space between the type identifier and the name
of the protocol encased in angle brackets.

Blocks

Blocks are preferred to the target-selector pattern when creating
callbacks, as it makes code easier to read. Code inside blocks should be
indented four spaces.

Naming

Naming rules are very important in maintainable code. Objective-C method
names tend to be very long, but this has the benefit that a block of code
can almost read like prose, thus rendering many comments unnecessary.

When writing pure Objective-C code, we mostly follow standard Objective-C
naming rules
. These naming guidelines may differ
significantly from those outlined in the C++ style guide. For example,
Google’s C++ style guide recommends the use of underscores between words
in variable names, whereas this guide recommends the use of intercaps,
which is standard in the Objective-C community.

Any class, category, method, or variable name may use all capitals for
initialisms
within the name. This follows Apple’s standard of using all capitals
within a name for initialisms such as URL, TIFF, and EXIF.

When writing Objective-C++, however, things are not so cut and dry. Many
projects need to implement cross-platform C++ APIs with some Objective-C
or Cocoa, or bridge between a C++ back-end and a native Cocoa front-end.
This leads to situations where the two guides are directly at odds.

Our solution is that the style follows that of the method/function being
implemented. If you’re in an @implementation block, use the
Objective-C naming rules. If you’re implementing a method for a C++
class, use the C++ naming rules. This avoids the situation
where instance variable and local variable naming rules are mixed within a
single function, which would be a serious detriment to readability.

File Names

File names should reflect the name of the class implementation that
they contain — including case. Follow the convention that your

project
uses.

Objective-C++

Within a source file, Objective-C++ follows the style of the
function/method you’re implementing.

Class Names

Class names (along with category and protocol names) should start as
uppercase and use mixed case to delimit words.

Category Names

Category names should start with a 2 or 3 character prefix
identifying the category as part of a project or open for general
use. The category name should incorporate the name of the class it’s
extending.

Objective-C Method Names

Method names should start as lowercase and then use mixed case.
Each named parameter should also start as lowercase.

Variable Names

Variables names start with a lowercase and use mixed case to delimit
words. Class member variables have trailing underscores. For example:
myLocalVariable, myInstanceVariable_. Members
used for KVO/KVC bindings may begin with a leading underscore
iff use of Objective-C 2.0’s @property isn’t
allowed.

Comments

Though a pain to write, they are absolutely vital to keeping our code
readable. The following rules describe what you should comment and where.
But remember: while comments are very important, the best code is
self-documenting. Giving sensible names to types and variables is much
better than using obscure names and then trying to explain them through
comments.

When writing your comments, write for your audience: the next

contributor
who will need to understand your code. Be generous — the next
one may be you!

Remember that all of the rules and conventions listed in the C++ Style
Guide are in effect here, with a few additional points, below.

File Comments

Start each file with a basic description of the contents of the file,
followed by an author, and then followed by a copyright notice and/or
license boilerplate.

Declaration Comments

Every interface, category, and protocol declaration should have an
accompanying comment describing its purpose and how it fits into the
larger picture.

Implementation Comments

Use vertical bars to quote variable names and symbols in comments rather
than quotes or naming the symbol inline.

Object Ownership

Make the pointer ownership model as explicit as possible when it falls
outside the most common Objective-C usage idioms.

Cocoa and Objective-C Features

Member Variables Should Be @private

Member variables should be declared @private.

Identify Designated Initializer

Comment and clearly identify your designated initializer.

Override Designated Initializer

When writing a subclass that requires an init... method,
make sure you override the superclass’ designated initializer.

Overridden NSObject Method Placement

It is strongly recommended and typical practice to place overridden
methods of NSObject at the top of an
@implementation.

Initialization

Don’t initialize variables to 0 or nil in the
init method; it’s redundant.

Avoid +new

Do not invoke the NSObject class method new,
nor override it in a subclass. Instead, use alloc and
init methods to instantiate retained objects.

Keep the Public API Simple

Keep your class simple; avoid "kitchen-sink" APIs. If a method doesn’t
need to be public, don’t make it so. Use a private category to prevent
cluttering the public header.

#import and #include

#import Objective-C/Objective-C++ headers, and
#include C/C++ headers.

Use Root Frameworks

Include root frameworks over individual files.

Prefer To autorelease At Time of Creation

When creating new temporary objects, autorelease them on
the same line as you create them rather than a separate
release later in the same method.

Autorelease Then Retain

Assignment of objects follows the autorelease then
retain pattern.

Avoid Accessors During init and dealloc

Instance subclasses may be in an inconsistent state during
init and dealloc method execution, so code in
those methods should avoid invoking accessors.

Dealloc Instance Variables in Declaration Order

dealloc should process instance variables in the same order
the @interface declares them, so it is easier for a reviewer
to verify.

Setters copy NSStrings

Setters taking an NSString, should always copy
the string it accepts.

Avoid Throwing Exceptions

Don’t @throw Objective-C exceptions, but you should be
prepared to catch them from third-party or OS calls.

nil Checks

Use nil checks for logic flow only.

BOOL Pitfalls

Be careful when converting general integral values to BOOL.
Avoid comparing directly with YES.

Properties

Properties in general are allowed with the following caveat: properties
are an Objective-C 2.0 feature which will limit your code to running
on the iPhone and Mac OS X 10.5 (Leopard) and higher. Dot notation
is allowed only for access to a declared @property.

Interfaces Without Instance Variables

Omit the empty set of braces on interfaces that do not declare any
instance variables.

Automatically Synthesized Instance Variables

For code that will run on iOS only, use of automatically synthesized
instance variables is preferred.

When synthesizing the instance variable, use
@synthesize var = var_; as this prevents accidentally calling
var = blah; when self.var = blah; is intended.

Cocoa Patterns

Delegate Pattern

Delegate objects should not be retained.

Model/View/Controller

Separate the model from the view. Separate the controller from the
view and the model. Use @protocols for callback APIs.

Revision 2.36

Mike Pinkerton

Greg Miller

Dave MacLachlan

靜水流深: cocos2D 存取rootViewController

要存取RootViewController的方法:

1.

AppDelegate.h 設定 

@property (nonatomic, retain) RootViewController *viewController;

AppDelegate.m 設定

@synthesize viewController;

2.要存取RootViewController的地方要

#import "AppDelegate.h"

#import "RootViewController.h"

之後用

RootViewController *rootViewCtr =  ((AppDelegate*)([UIApplication sharedApplication].delegate)).viewController;

取得RootViewController進行操作.

(译)如何使用cocos2d开发一个简单的iphone游戏:旋转炮塔。(第二部分) – 子龙山人 – 博客园

子龙山人

Learning,Sharing,Improving!

(译)如何使用cocos2d开发一个简单的iphone游戏:旋转炮塔。(第二部分)

 免责申明(必读!):本博客提供的所有教程的翻译原稿均来自于互联网,仅供学习交流之用,切勿进行商业传播。同时,转载时不要移除本申明。如产生任何纠纷,均与本博客所有人、发表该翻译稿之人无任何关系。谢谢合作!

原文链接地址:http://www.raywenderlich.com/692/rotating-turrets

 《怎样使用cocos2d来开发一个简单的iphone游戏》这个帖子太火了,你们当中的许多人都想要一些后续的教程!特别是,有些人问到我如何旋转炮塔来改变射击的方向。许多游戏都有这个功能,包括我最喜欢的一款游戏—-塔防!

 因此,在这个教程中,我将会详细地讲解如何实现这个功能,即如何把旋转炮塔的功能添加到一个游戏当中去。在这里,特别要感谢Jason和Robert,是他们建议我来写这篇教程。

准备工作

  如果你看完并实践了上一个教程,你可以继续使用那个工程。如果没有的话,那么下载这个链接的代码吧。

  接下来,下载新的 player sprite 和 projectile sprite图片,然后把它们加到工程里面,在这之前,先从工程里删除旧的Player.png和Projectile.png图片。然后,修改代码,把每个sprite添加进去。如下所示:

// In the init methodCCSprite *player = [CCSprite spriteWithFile:@"Player2.png"];// In the ccTouchesEnded methodCCSprite *projectile = [CCSprite spriteWithFile:@"Projectile2.png"];

  注意,这一次我们并没有指定精灵的宽度和高度,而是让cocos2d替我们来处理这些事情。

  编译并运行你的工程,如果一切顺利的话,你将会看到一个炮塔正在发射子弹。然后,这并不是很好,因为炮塔在射击的时候并没有面朝那个方向。因此,接下来让我们来解决这个问题。

旋转并射击

  在我们旋转炮塔之前,首先,我们需要保存Player精灵的引用,以便后面旋转它的时候使用。打开HelloWorldScene.h,然后修改类文件并包含以下成员变量:

CCSprite *_player;

 

然后修改init方法中的代码,把Player对象加入到层(layer)中。代码如下:

_player = [[CCSprite spriteWithFile:@"Player2.png"] retain];_player.position = ccp(_player.contentSize.width/2, winSize.height/2);[self addChild:_player];

  最后,我们在dealloc函数里面添加一些清除代码。(这是个好习惯,初使化后就做相应的清理操作,防止忘记。)

[_player release];_player = nil;

  好了,现在让我们取出player对象的引用并且旋转它吧!为了旋转它,我们首先需要计算出旋转的角度。为了解决这个问题,想想我们在高中时候学过的三角代数吧。还记得sin cos tan吗?为了便于理解,下面使用一张图来解释一下:tan = 对面/邻边。

alt

  如上所示,我们想要旋转的角度是arctangent(angle),即对offY/offX求arctangent运算。

  然而,这里还有两件事情,我们需要放在心上。首先,当我们计算actangent(offY/offX)的时候,这个结果是弧度,但是cocos2d使用的却是角度。还好,cocosd2d提供了一个非常方便的宏,可以使得角度和弧度之间方便转化。

  第二点,我们假定上面的图中angle的偏转是正20度,但是,cocos2d里面顺时针方向为正(而不是上图所示的逆时针为正)。让我们看到下面这个图:

  因此,为了得到正确的方向,我们把运算结果乘以一个-1就可以了。比如,如果我们把上面那幅图片里的角度乘以-1的话,我们就得够得到-20度,这个角度其实就是逆时针方向的20度。(感觉老外说话好啰嗦啊,聪明的读者恐怕早就明白了吧!:)

  好了,讲得够多了!让我们来写一点代码吧。在ccTouchesEnded里面加入以下代码,添加位置在你的projectile runAction之前。

// Determine angle to facefloat angleRadians = atanf((float)offRealY / (float)offRealX);float angleDegrees = CC_RADIANS_TO_DEGREES(angleRadians);float cocosAngle =1* angleDegrees;_player.rotation = cocosAngle;

 

  编译并运行工程,现在我们的炮塔在射击的时候可以改变方向了。

旋转之后再射击

  目前来说还不错,但是有一点点怪。因为,这个炮塔好像突然一下跳到一个方向射击,有点不够流畅。我们可以解决这个问题,但是在这之前,我们需要重构一下代码。

  首先,打开HelloWorldScene.h,然后在你的类里添加如下成员变量:

CCSprite *_nextProjectile;

 

  然后,修改你的ccTouchesEnded方法,并且添加一个新的方法,叫做finishShoot,如下所示:

复制代码

(void)ccTouchesEnded:(NSSet *)touches withEvent:(UIEvent *)event {if (_nextProjectile != nil) return;// Choose one of the touches to work withUITouch *touch = [touches anyObject];CGPoint location = [touch locationInView:[touch view]];location = [[CCDirector sharedDirector] convertToGL:location];// Set up initial location of projectileCGSize winSize = [[CCDirector sharedDirector] winSize];_nextProjectile = [[CCSprite spriteWithFile:@"Projectile2.png"] retain];_nextProjectile.position = ccp(20, winSize.height/2);// Determine offset of location to projectileint offX = location.x _nextProjectile.position.x;int offY = location.y _nextProjectile.position.y;// Bail out if we are shooting down or backwardsif (offX <=0) return;// Play a sound![[SimpleAudioEngine sharedEngine] playEffect:@"pew-pew-lei.caf"];// Determine where we wish to shoot the projectile toint realX = winSize.width + (_nextProjectile.contentSize.width/2);float ratio = (float) offY / (float) offX;int realY = (realX * ratio) + _nextProjectile.position.y;CGPoint realDest = ccp(realX, realY);// Determine the length of how far we’re shootingint offRealX = realX _nextProjectile.position.x;int offRealY = realY _nextProjectile.position.y;float length = sqrtf((offRealX*offRealX)+(offRealY*offRealY));float velocity =480/1; // 480pixels/1secfloat realMoveDuration = length/velocity;// Determine angle to facefloat angleRadians = atanf((float)offRealY / (float)offRealX);float angleDegrees = CC_RADIANS_TO_DEGREES(angleRadians);float cocosAngle =1* angleDegrees;float rotateSpeed =0.5/ M_PI; // Would take 0.5 seconds to rotate 0.5 radians, or half a circlefloat rotateDuration = fabs(angleRadians * rotateSpeed); [_player runAction:[CCSequence actions:[CCRotateTo actionWithDuration:rotateDuration angle:cocosAngle],[CCCallFunc actionWithTarget:self selector:@selector(finishShoot)],nil]];// Move projectile to actual endpoint[_nextProjectile runAction:[CCSequence actions:[CCMoveTo actionWithDuration:realMoveDuration position:realDest],[CCCallFuncN actionWithTarget:self selector:@selector(spriteMoveFinished:)],nil]];// Add to projectiles array_nextProjectile.tag =2;} (void)finishShoot {// Ok to add now – we’ve finished rotation![self addChild:_nextProjectile];[_projectiles addObject:_nextProjectile];// Release[_nextProjectile release];_nextProjectile = nil;}

复制代码

 

  这看上去好像有许多代码,但是,实际上我们改动的并不多–大部分只是做一些小小的重构。下面是我们所修改的内容的一个列表:

  1.在函数开头检查nextProjectile的值是否为nil。这意味着我们当前的touch事件正发生在射击过程之中。也就是说,炮塔已经发射出一个子弹了。

  2.之前,我们使用一个projectile的局部变量,并把它加入到了当前的场景中。在这个版本中,我们增加了一个nextProjectile的成员变量,但是并没有马上加到当前场景中。因为后要还要使用。

  3.定义炮塔旋转的角度,半秒钟旋转半个圆。记住,一个圆有2 PI个弧度。

  4.计算旋转特定的角度需要多长时间,这里是拿弧度乘以速度。

  5.接下来,我们使用一个sequence action来旋转我们的炮塔。最后,调用一个函数,把projectile加入到当前场景当中去。

  好,大功告成!编译并运行工程,现在炮塔可以旋转,并且很流畅地射击了!

接下来做什么?

  首先,这里有《怎样使用cocos2d来开发简单的iphone游戏》目前为止的完整代码。

  接下来,在这个系列的教程中,我们教大家如何添加更猛的怪物和更多的关卡

  或者期待我接下来翻译的cocos2d和box2d方面的教程吧!

 

著作权声明:本文由http://www.cnblogs.com/andyque翻译,欢迎转载分享。请尊重作者劳动,转载时保留该声明和作者博客链接,谢谢!

分类:

[转]苹果应用商店审核指南中文翻译 | luoyl’blog

官方英文原版:https://developer.apple.com/appstore/guidelines.html

前言

我们很高兴您付出宝贵的才华与时间来开发iOS应用程序。从职业与报酬的角度而言,这对于成千上万的开发员一直都是一项值得投入的事业。我们希望帮助您加入 这个成功的组织。这是我们首次发布《应用程序商店评估指导》(App Store Review Guidelines)。通过它,我们希望帮助您解决开发应用程序时遇到的问题,以便于您在提交应用程序时,可以加快审批流程的速度。

我们将应用程序(Apps) 视为与书籍或歌曲不同的产品,我们并不存储它们。如果您意欲批评宗教,那就去写本书。如果您想要描述性爱过程,写本书或写首歌曲,或者可以创建一个医疗程 序。这会出现非常复杂的局面,但是我们决定,在应用程序商店(App Store)禁止出现某种内容。这或许会让您认识到我们秉持的更为深远的目的:

我们拥有许多儿童可以下载的应用程序,除非父母事先进行了设置(一般父母都不会设置),否则父母对这些内容的操作控制将会无效。因此,您要了解我们时刻在留意着您的孩子。

在我们的应用程序商店中已经拥有了超过 25万个应用程序。我们不再需要那些垃圾应用程序。如果您的应用程序没有什么有益的用途或者持续性的娱乐功能,则可能不会获得我方的接受。

如果您的应用程序看上去像是那种只花了几天功夫简单拼凑出来的产品,或者只是想在我们的商店中抓住朋友的眼球,请提前做好遭拒的准备。我们有很多具有严谨态度的开发程序员不希望他们的高品质应用程序充斥在一些业余作品之中。

我们将拒绝任何包含越界内容或行为的应用程序。您可能会问道,具体限制是什么?最高法院的法官曾有言:“它出现时我自然心中有数。”当您越过这一范围时,我们认为您也会有自知之明。

如果您的应用程序被拒,我们设立了一个审查委员会供您上诉。如果您去媒体抨击我们,肯定对您于事无补。

这是一个动态文档,新提交的应用程序会导致新的问题产生,并可能随时产生新的规则。或许您的应用程序会触及到这一点。

最后要说明的是,我们非常珍惜这个平台,并且向您的作品表示敬意。我们确实在尝试尽力创建全球最佳平台,以便让您展示才华,同时获得相应的报酬。如果这读上去让您感觉我们的控制欲过强,那是因为我们曾向用户承诺保证,我们将利用我们的产品让他们获得高品质体验。

目录

 

1. 条款和条件

1.1 为App Store开发程序,开发者必须遵守程序许可协议(PLA)、人机交互指南(HIG)以及开发者和苹果签订的任何协议和合同。以下规则和例子旨在帮助开发者的程序能获得App Store的认可,而不是修改或删除任何其他协议中的条款。

 

2. 功能

2.1 崩溃的程序将会被拒绝

2.2 有错误的程序将会被拒绝

2.3 跟开发者宣传不符的程序将会被拒绝

2.4 无应用文档或隐藏功能与描述不符的程序将会被拒绝

2.5 使用非公开API的程序将会被拒绝

2.6 在指定容器范围外读写数据的程序将会被拒绝

2.7 以任何方式或形式下载代码的程序将会被拒绝

2.8 安装或释放其他可执行代码的程序将会被拒绝

2.9 beta版、演示版、trial版和测试版的程序将会被拒绝

2.10 iPhone程序必须不经修改就能以iPhone分辨率和2倍 iPhone 3GS的分辨率在iPad上运行

2.11 与App Store已有程序重复的程序可能会被拒绝,特别是数量很多的情况下

2.12 没有显著用途或不提供任何持久娱乐价值的程序可能会被拒绝

2.13 主要内容为营销或广告的程序将会被拒绝

2.14 欺骗或有虚假功能,没有明确标明的程序将会被拒绝

2.15 大于20MB的程序不会通过蜂窝网络下载(App Store会自动禁止)

2.16 多任务程序仅可以为达到预期目的而使用后台服务:网络电话、音频播放、地点、任务完成、本地通知等

2.17 浏览网络的程序必须使用iOS WebKit框架和WebKit Javascript

2.18 鼓励过量饮酒或非法物质,或鼓励青少年饮酒或吸烟的程序将会被拒绝

2.19 提供不正确诊断或其他不准确设备数据的程序将会被拒绝

2.20 向App Store上传大量相似版本程序的开发者将会从iOS开发者项目中除名
 

 

3. 元数据(名称、描述、评级、排名等)

3.1 带有任何其他移动平台名称的元数据程序将会被拒绝

3.2 带有占位符文本的程序将会被拒绝

3.3 带有与程序内容和功能不相关描述的程序将会被拒绝

3.4 连接到 iTunes 中的程序名称及显示在设备的程序名称应该相似,不至引起混淆

3.5 程序的大图标与小图标应该类似,不至引起混淆

3.6 程序图标与画面不符合4+年龄评级的程序将会被拒绝

3.7 目录与类型不适合于程序内容的程序将会被拒绝

3.8 开发程序员负责为其程序指定适合的评级。评级不适用可能会由苹果公司修改

3.9 开发程序员负责为其程序指定适合的关键字。关键字不适用可能会由苹果公司修改/删除

3.10 利用伪造或付费评论的方式在App Store中企图操纵或欺骗用户评价或图表排名的开发程序员(或者采用其他不正当方式)将会从iOS开发者项目中除名
 

 

4. 位置

4.1 在采集、传送或使用位置数据之前未通知并获得用户同意的程序将会被拒绝

4.2 使用基于位置的API用于车辆、飞机或其他设备的自动控制或自主控制的程序将会被拒绝

4.3 使用基于位置的API用于调度、车队管理或应急服务的程序将会被拒绝
 

 

5. 推送通知

5.1 不采用苹果推送通知 (APN)应用接口提供推送通知的程序将会被拒绝

5.2 未从苹果获得推送应用ID便擅自使用APN服务的程序将会被拒绝

5.3 未获得用户初次同意便发送推送通知的程序将会被拒绝

5.4 使用推送通知发送敏感个人信息或机密信息的程序将会被拒绝

5.5 使用推送通知发送非请求消息或用于钓鱼或群发垃圾邮件用途的程序将会被拒绝

5.6 程序不可使用推送通知发送广告、促销或任何类型的直销

5.7 程序不能向使用推送通知服务的用户收取费用

5.8 使用推送通知会利用过多APN服务的网络流量或带宽或给设备带来过度负担的程序将会被拒绝

5.9 如果程序能够传送病毒、文件、计算机代码或程序,并且对APN服务的正常运行造成损害或中断,该程序将会被拒绝
 

 

6. 游戏中心

6.1 向终端用户或任意第三方显示玩家ID的程序将会被拒绝

6.2 将玩家ID用于任何未经游戏中心条款批准用途的程序将会被拒绝

6.3 企图进行反向查找、跟踪、关联、挖掘、获得或利用玩家ID、化名或通过游戏中心获得的其他信息将会从iOS 开发程序员项目中除名

6.4 游戏中心信息(例如计分板得分)可能仅能用于游戏中心批准的程序

6.5 利用游戏中心服务发送非请求信息或用于钓鱼或群发垃圾邮件的程序将会被拒绝

6.6 过多使用游戏中心网络流量或带宽的程序将会被拒绝

6.7 如果程序能够传送病毒、文件、计算机代码或程序,并且对游戏中心服务的正常运行造成损害或中断,该程序将会被拒绝
 

 

7. iAd相关

7.1 人工增加访问次数或者广告点击量的应用程序将会被拒绝

7.2 包含有空的iAd广告栏的应用程序将会被拒绝

7.3 主要设计目的在于显示广告的应用程序将会被拒绝
 

 

8. 商标与商业外观

8.1 应用程序必须遵守使用苹果商标和版权以及苹果商标列表指导手册中说明的所有条款与条件

8.2 任何误导和暗示苹果公司是该应用程序来源或提供商,或者苹果公司以任何形式表示认可其质量或功能的应用程序将会被拒绝

8.3 与目前已有苹果产品或者广告主题外观相似混淆的应用程序将会被拒绝

8.4 在应用程序名称中将苹果产品名拼错的应用程序(例如,GPS for Iphone, iTunz)将会被拒绝

8.5 使用受保护的第三方材料(商标、版权、商业机密、其他私有内容)在申请时需要提供一份文本形式的版权确认

8.6 当原内容所有的商标特征保持不被修改并完整显示时, 谷歌地图和通过谷歌地图API获取的谷歌地球的图像可以在应用程序内部使用。掩盖或者修改谷歌标志或者版权拥有者身份证明的应用程序将会被拒绝
 

 

9. 媒体内容

9.1 不使用媒体播放器框架(MediaPlayer Framework)获取音乐库中媒体的应用程序将会被拒绝

9.2 模仿任何iPod界面的应用程序将会被拒绝

9.3 通过蜂窝网络传输的音频流内容每5分钟不得大于5MB

9.4 通过蜂窝网络传输超过10分钟的视频流内容需要使用HTTP直播流(HTTP Live Streaming)并包含一个亟待64kbps仅音频的HTTP直播流
 

 

10. 用户界面

10.1 应用程序必须遵守苹果《iPhone用户界面指导原则》以及《iPad用户界面指导原则》中解释的所有条款和条件。

10.2 与App Store、iTunes Store和iBookstore等提供的iPhone捆绑应用程序类似的应用程序将会被拒绝。

10.3 未能按苹果《iPhone用户界面指导原则》及《iPad用户界面指导原则》所述,正确使用系统自带的按钮、图标等项目的应用程序可能会被拒绝。

10.4 创建alternat桌面/主屏幕环境或者模拟多应用程序widget体验的应用程序将会被拒绝。

10.5 改变音量大小和铃声/静音开关等标准开关功能的应用程序将会被拒绝。

10.6 苹果及我们的客户高度推崇简单、精致、富有创造性以及经过精心设计的界面。虽然需要付出更多,但却非常值得。苹果设立了很高的门槛。如果你的用户界面太过复杂或者水准不高,可能会被拒绝。
 

 

11. 购买与货币

11.1 使用App Store以外的软件开启或提供额外功能的应用程序将会被拒绝。

11.2 使用应用内支付系统(IAP)以外的系统购买内容、功能或服务的应用软件将会被拒绝。

11.3 使用IAP购买实物商品和并非用于该软件的服务的应用软件将会被拒绝。

11.4 应用软件使用IAP购买信用点或者其他货币必须消费本软件内的信用点。

11.5使用IAP购买已过期信用点或者其他货币的应用软件将会被拒绝。

11.6使用IAP订阅内容最少需持续30天,所有iOS设备用户都可使用这项功能。

11.7 应用软件使用IAP购买的商品必须具有可购买性。

11.8 使用IAP购买iOS提供的照相摄像或陀螺仪等内置功能的应用软件将会被拒绝。

11.9 含有已超过限定时间的“出租”内容或服务的应用软件将会被拒绝。

11.10 保险应用软件必须免费,遵守发布地区的法律同时不能使用IAP。

11.11 一般而言,你的应用程序越贵,我们的评审越彻底。
 

 

12. 抓取和聚合

12.1 从苹果网站(例如apple.com、iTunes Store、App Store、iTunes Connect、苹果开发者计划等)抓取任何信息或者使用苹果网站的内容和服务进行排名的应用软件将遭到拒绝。

12.2 应用软件可以使用获得批准的苹果RSS feeds,例如iTunes Store RSS feeds。

12.3 只是简单的网页剪切、内容聚合器或者罗列链接的应用软件可能会被拒绝。
 

 

13. 设备损害

13.1 怂恿用户以可能造成损害的方式使用苹果设备的应用软件将会被拒绝。

13.2 快速耗光设备电量或产生过多热量的应用软件将会被拒绝。
 

 

14. 人身攻击

14.1 具有诽谤、人身攻击性质以及内容狭隘卑鄙的应用软件或者打击特定个人或组织的应用软件将会被拒绝。

14.2 职业政治讽刺家不受这一禁令约束,可进行具有攻击性或狭隘刻薄的评论。
 

 

15. 暴力

15.1 应用程序中出现人或动物被杀、致残以及枪击、刺伤、拷打等受伤情形的真实画面将会被拒绝。

15.2 出现描绘暴力或虐待儿童等内容的应用程序将会被拒绝。

15.3 游戏中出现的“敌人”不可指向一个特定种族、文化、一个真实存在的政府、企业或者其他任何现实中的实体。

15.4 对武器进行真实描述以怂恿非法使用或滥用这些武器的应用程序将会被拒绝。

15.5 内含与俄罗斯轮盘相关的应用程序将会被拒绝。
 

 

16. 不当内容

16.1 应用程序中出现过于令人反感或者低俗的内容将会被拒绝。

16.2 在设计上用于激怒用户或令人感到厌恶的应用程序将会被拒绝。
 

 

17.隐私

17.1 应用程序不能在未获用户允许或未向用户提供如何使用及在何处使用数据的相关信息情况下传输有关用户的数据。

17.2 要求用户共享电子邮箱地址和出生日期等私人信息才可使用其功能的应用程序将会被拒绝。

17.3 锁定未成年人进行数据收集的应用程序将会被拒绝。
 

 

18. 色情

18.1 含有色情素材,也就是《韦氏词典》中定义的“旨在激发情欲,对性器官或性行为的明确描述或展示,而无关美学或情绪感受”的程序将会被拒绝

18.2 用户产生内容多为色情的程序(比如以前的Chat Roulette程序)将会被拒绝
 

 

19.宗教,文化与种族

19.1 涉及宗教、文化或种族群体的引用或评论包含诽谤性、攻击性或自私性内容,或会使特定群体遭受伤害或暴力的程序将会被拒绝

19.2 程序可以包含或引用宗教经文,程序所提供的引用或翻译必须准确且不会引起误导。评论应该有教育意义,可以令人开阔眼界,而不应有煽动性
 

 

20.竞赛、赌金、彩票与抽彩售物

20.1 赌金和竞赛必须由程序的开发者公司发起

20.2 赌金和竞赛的正式规则必须在程序中注明,并且必须明确表示苹果不是发起者,也没有以任何方式参与活动

20.3 开发者运营的彩票程序必须在法律容许范围之内,彩票程序必须具有以下所有特性:报酬、几率及奖品

20.4 允许用户直接购买彩票或抽彩售物券的程序将会被拒绝
 

 

21.慈善与援助

21.1包含可以向认证的慈善组织捐赠功能的程序必须是免费的

21.2 捐赠款项的募集必须通过Safari浏览器中的网站或是手机短消息。
 

 

22. 法律要件

22.1 程序必须遵守各地用户遵守的任何法律要求。开发者有义务了解并遵守当地所有法律

22.2 包含虚假,欺诈或误导性陈述的程序将会被拒绝

22.3 请求、促进或鼓励犯罪或明显鲁莽行为的程序将会被拒绝

22.4 使用非法文件共享的程序将会被拒绝

22.5 被设计用作非法赌博辅助工具,包括算牌的程序将会被拒绝

22.6 具有拨打匿名或恶作剧电话或发送类似短信彩信功能的程序将会被拒绝

22.7 开发暗中收集用户密码或用户私人数据程序的开发者将会从iOS开发者项目中除名

 

动态文档

这份文档展现了我们在竭尽所能向您分享我们对提交到App Store的程序的审查方式,我们希望您在开发和提交程序时,这份指南能对您有所帮助。这是一份动态文档,随着新程序和新情况的发生会有所变化。我们会定期更新,以反映这些变化。

感谢您参与到iOS的开发中来。虽然此文档是一份“不该做事宜”的列表,但也请将那份短得多的“必做事宜”列表牢记在心。最重要的是,与我们一道共同努力让用户感到惊奇和欣喜。用创新方式向他们展示世界,让他们用前所未有的方式与之交流。根据我们的经验,无论是在功能和用户界面上,用户确实会对完善的程序有所反应。更进一步,给他们期望之外的东西,带他们去从未去过的地方。我们愿意提供帮助。

YM’S BLOG: AmfPHP介绍及资源

AmfPHP介绍及资源

Amfphp 是PHP的RPC工具,它可以使PHP与下述技术无缝通信:

  • Flash 和 Flex Remoting
  • JavaScript JSON 和 Ajax JSON
  • XML 和XML-RPC

一、什么是RPC?

远端程序调用(RPC, Remote Procedure Call) 是一种客户端与服务器端交换数据方式。我们可以调用本地对象的带有不同参数的方法 ,设置回调并接受调用结果。我们不用关心发送和接收数据的实现细节。实现细节通常是抽象的, 就像我们在调用本地方法一样.

二、工作原理

客户端(Flash)与服务器端(php), 使用相同的方式描述方法调用和复杂数据。客户端序列化请求并将它发送到网关Amfphp。Amfphp再执行:

  • 反序列化请求
  • 找到相应的远程服务类
  • 实例化类
  • 执行安全检查
  • (使用指定参数)调用服务器端方法
  • 序列化返回的数据

Amfphp 可以正确地序列化、反序列化复杂类型数据。除了对象和数组,它还支持数据连接资源,这就意味着我们可以通过调用远程方法简单返回 mysql_query,amfphp 会处理这一切。 如果平台支持 (目前来说,Flash Remoting 和Flex Remoting), phpamf还可以处理循环引用和自定义数据。 它也支持简单的远程调试。还有amfphp 附带一个服务浏览器,它可以在创建客户端代码前测试远程服务。amfphp 1.0.1还添加了模板,可以自动生成客户端代码。Amfphp 1.9 beta更是新增了对AMF3的支持。详见http://www.riafan.com/article.asp?id=31

三、教学资源

1. 英文

2. 中文

AMFPHP基本安全问题_新长征路上的游魂_百度空间

AMFPHP基本安全问题

2008-11-09 20:58

原文:http://theflashblog.com/?p=419

1. 删除Service Browser
因为对你有用的服务和方法对其他任何来说也一样能用,很明显,为此你需

要在你的产品机上删除它。最简单的就是删除位于AMFPHP根目录的Browser

文件夹

2.删除DiscoveryService 服务
DiscoveryService 服务再你安装AMFPHP的时候就被包含进来,这个服务会暴

露所有有效的服务和方法的详细信息,为了安全期间,整个删除AMFPHP/services文件夹

下的amfphp目录或者只删除DiscoveryService.php文件

3.设置PRODUCTION_SERVER属性
PRODUCTION_SERVER属性位于根目录AMFPHP下的gateway.php中,默认值是

false,在产品机上应该设置为true,这样它会禁止一些类似远程开发调试的

头信息的东西。

4.如果可能的通过SSL来运行服务
通过SSL,flash和php之间的数据交换将是加密传输的,让sniff很难发现真

实的数据。

5.使用beforeFilter进行认证
在AMFPHP 1.9版本增加了一个新特色,让你能够认证调用者是否有访问服务

的权限。在你的服务类里添加一个叫做“beforFilter”的方法:

public function beforeFilter($function_called)

这个函数在客户端调用服务端方法的时候呗调用,如果返回true,方法将被

执行,返回false,则抛出一个错误,在这个方法里你可以做一些认证逻辑。

这方面Joshua Ostrom写了一篇很不错的博客:

http://www.joshuaostrom.com/2008/06/03/securing-amfphp-19-via-authentication/

6.PHP的基本安全
AMFPHP毕竟是使用PHP的,务必了解一些基本的PHP安全方面的知识,比如如

何放置SQL注入等。关于这方面,推荐阅读“Essential PHP Security ”