Forms AuthWindows Auth – what is more common?


I was talking to some coworkers today about the scenarios for Forms Auth and Windows Auth in line of business applications.    We were having a debate about which was more common.

As you might guess at Microsoft we are an all windows shop, so just about all our line of business applications use Windows auth, and I gotta say it is pretty nice not to have to remember a bunch of user names and passwords.  

But I wonder if that is so common across the industry.. and even for companies that do use Windows Auth, I imagine there are scenarios where Forms auth is still important. 

One place this manifests itself is in the project templates  for things like ASP.NET MVC, ASP.NET WebForms, Silverlight, etc.  Should we be wiring these up to support Forms Auth by default (with a log in\register controls) or Windows Auth where those are not needed?

Here is a little forms auth example… 

image

 

What do you think?  What is more common in your experience Forms auth or Windows Auth?

Comments (93)

  1. Bill Moore says:

    Personally i usually use forms auth for almost anything web based.  In ten years I have only used windows auth a handful of time.

  2. Joe Enos says:

    I’ve always used forms authentication in my companies.  It’s more "webby", so it seems that web developers and architects may be more familiar with it over Windows authentication.  Obviously Windows authentication has plenty of advantages, but if you’ve got custom user data in your database already, which any application I’ve worked with does, then it’s reasonably trivial to add authentication and basic user management on top of that.

    I’m not opposed to Windows authentication, just not my first choice.

  3. Paul Jackson says:

    +1 for Forms Auth

    Echo Bills Moore’s comment.

  4. I use forms auth for almost everthing which is available from the internet. In intranet scenarios (e.g. in combination with SharePoint) Windows Auth is a great feature.

  5. Most of time we a requested to use Forms Auth, often combined with some additional auth Web Service.

  6. PK says:

    Forms Auth all the way.

    OpenId is taking over also, IMO .. but that’s using Forms Auth on another server.

    Never had a use for Windows Auth.

  7. Robert says:

    Never used Forms Auth. Even for public facing websites we use windows auth.

    Have to say that I’m in a enterprise environment with high security constraints where the public facing websites are secured using two-factor authentication (think hardware token) and having only a limited number of clients.

  8. Jacob Rohde says:

    Definitely Forms Auth. But as a web developer I guess that’s the norm.

  9. What's New says:

    I was talking to some coworkers today about the scenarios for Forms Auth and Windows Auth in line of

  10. The whole discussion about authentication types becomes more and more moot.

    Since Microsoft and the rest of the industry is moving towards token based authentication (active & passive), RIA Services and thus SL should directly support Geneva based apps and services and Geneva Server.

    my 2c

    Dominick

  11. Filip Cornelissen says:

    +1 for Windows Auth 🙂

    Since we are also all windows in our company, i use Windows Auth for our internal web applications.

  12. It always depends on the project and the target group that will use it. In most of the web projects we use Forms Auth, but sometimes even both are needed. With our last Silverlight project we knew that it will be used only within a certain enterprise network so we went with Windows auth, thus not having the users to create new accounts just to use that specific application. Windows auth is my preferred choice when it can be used, but in my practice most of the web applications require Forms auth.

  13. I’d have to say Forms Auth (even on desktop apps). I cheer every time we get to use Windows Auth!

    (I don’t know why. Maybe I need help?)

  14. Bhaskar Ganapathe says:

    I use Windows auth for all my internal web applications targetted for business users.

  15. Joannes Vermorel says:

    +1 Bill Moore

    Used form auth dozens of times; but never implemented windows auth. Now, we are shifting toward OpenID though.

  16. Tim Dawson says:

    In all my years of web development I only used forms auth. The fact is that most or a lot of websites are hosted on servers on which the developer or owner of the site doesn’t have the level of control needed to create windows users. Forms auth will "just work" wherever the website is deployed.

  17. Mark Cassidy says:

    For LOB, Windows Auth is dominant in my experience.

    I guess most commenters miss that part – and are thinking "open internet" – OpenID has little place in any LOB application I’ve been part in developing 😉

  18. Thank you for submitting this cool story – Trackback from DotNetShoutout

  19. Scriv says:

    I think I’ve only really ever worked with Forms auth. Some of our apps that run in the internet and intranet use Windows internally but Forms externally though.

    There’s lots of talk about us moving to Geneva here though and that could happen pretty soon.

  20. Thomas Stark says:

    Generally we always try to use Windows Authentication for LOB’s.  Often I wan’t to impersonate the user and therefore I want Windows Auth.  It’s just easier to use Windows Auth.

    Only for really simple apps where there is no need to know a users name or other data would be use Forms Authentication – it’s really seldom.

  21. Eoin C says:

    I’ve only ever used Forms Auth 🙂

  22. Riaz Hassan says:

    I have always used Forms Authentication. In my experience forms authentication gives more control over the rights in a particular domain, may be thats the reason most of the architects are using forms authentication.

  23. Cristovao Morgado says:

    Forms Auth all the way. because Win Auth is so simple that we don’t need to code it 🙂

  24. Bigsby says:

    I use neither. I prefer to use myown auth stuff. It’s cleaner, faster and less dependent.

  25. barryd says:

    you left out one, claims based 🙂

  26. DaveP says:

    Windows auth for our enterprise apps

    Forms auth for our public apps

  27. We develop enterprise apps mostly using Windows Authentication.

  28. Rachida Dukes says:

    Personally i usually use forms auth for almost anything web based application

  29. Matt says:

    I use a Forms Authentication for all web applications although it would obviously make sense to use Windows Authentication for private or enterprise type   applications where you have your own server, if you run on shared hosting I don’t think you are likely to get access to a bunch of windows user accounts.

  30. Steve says:

    If it’s an intranet app, windows auth (where possible) otherwise forms auth.

  31. Matthew says:

    Intranet web based application’s we always use Windows Auth – We have > 100 applications. We use a central admin type scenerio to administer roles per application.

  32. Steve says:

    Both  ðŸ™‚

    Windows Auth for intranet sites, and I’ve used Forms Auth (love it) for my internet sites

    I like that it’s included in the templates.

  33. Eyston says:

    I use windows auth whenever possible.  We have several 3rd party apps that have their own authentication system and there is a ton of negative feedback from employees on having to remember 3, 4, 5, etc passwords.

    When demoing an application I was working on it was noticed that it required authentication to perform some actions (shipping has their role, accounting theirs, etc).  There was a bunch of moaning until I showed them that they never had to ‘logon’ and that it used their windows account automatically — they were happy.

    That said, I am probably going to be working on a public facing vendor portal.  While there are some solutions out there to share form auth and windows auth, it seems wonky (especially for IIS7).  I’ll probably end up deploying the application twice — once public facing with forms auth backed by an SQL Server User Provider and the second for intranet use with windows.  The nice thing about providers is it can be nearly 100% (maybe even 100%) the same code.

  34. Bert says:

    Windows Auth.  Geneva would be great, but its going to take years for enterprises to get around to installing those types of servers.  How many people here know anything about AD FS, much less are using it (for the right reasons) already? And AD FS is several years old!

  35. Aegean Shark says:

    Definitly forms authentication its easy to use also i don’t want to expose internal credentials to web.

  36. apple says:

    It is important for us that Administrators can configure our systems so that users need to enter username and password explicitly, sometimes even repeatedly when they perform certain actions.

    Therefore we go with Forms authentication but allow the Membership Provider to be configured to use e.g. Active Directory or a custom provider.  This way we achieve the following:

    – users do not have to remember another password

    – Admins can manage their password policies etc. in the usual way

    – Admins can configure, as part of the Membership provider, how long credentials are persisted, we allow for an option to define wether a Remember Me option shall appear on the form or not. This means you can configure authentication to require explicit log-on all the time or remember a user indefinitely, provided they don’t clear out their cookies.

    – Roles can still be managed via an internal UI, meaning you could have system users defining roles rather than having to bother an NT administrator all the time.

  37. apple says:

    Forgot, about your question regarding pre-wiring:

    I find the current ASP.NET implementation very easy to use. I wouldn’t need/want the authentication type pre-wired, because often I need both and just swap/comment out one in the config file.

    One qualm I have is that all prebuilt components and authentication services only cater for login sucess or failure. However, if login fails I want to take diferent action whether this is due to

    – user does not exist

    – wrong password

    – is inactive

    – is locked out

    – potentially even something else based on LastActivity, LastPassword change or a Comment entry etc.

    I find that I have to manually create extensions or workarounds to manage this. Why can’t you get a handle on the MembershipUser by default (both for login sucess and failure?)

  38. Ian Ringrose says:

    I have worked for ISVs, we have always had to provide support for Forms Authentication, and some of our customers like support for Windows Auth.  However it is normal to have to talk to 3rd party single sign on systems, and/or ldap directories.  

    Often even if the customer is using Active Directory they don’t have everyone they wish to use the software in their Active Directory, they also often wish staff to be able to use the systems from home without a VPN.  It is common to import all users form another system (or spread sheet) and then email then all a generated password with the request to that they make use of the system.

    All the above has to be able to be done by editing configuration file as our support people don’t get to change the code of the systems we sell.  Our software is installed on servers in the customer’s computer rooms, but is mostly “web based”.

    It is very common for customers to not even know if they already have a single-sign-on system deployed.  As to finding out if they have all users Active Directory – that can take weeks AFTER the go-line date!  Therefore Forms Authentication with the username and password in our own database tables, must always be provided as a fallback.

  39. David says:

    Forms Auth at a ratio of 10 to 1.

  40. Rob says:

    Windows auth on intranet and forms auth on internet.

  41. Jonx says:

    I’m for Forms auth… Then one question, is it possible in a winform application to use the Forms auth underlying mecanisms?

  42. Mike Swaim says:

    I almost always use forms authentication, because I have a fair number of external users. Also, if you do your logging in the database using DB user IDs, windows authentication requires extra server configuration stuff be done (unless your web server and db server are on the same box).

  43. Margo says:

    Windows Auth is completely out of the question for anyone doing a web-based app.  Why would I pay for AD licenses for my customers to log in to my site?  

    Now, in my 10+ years of web development, the common scenario is that I have "internal" (ie, employees in the office on domain computers) logging into the same web app that my external customers are.  It would be nice to have an "either-or" situation.  We’ve always just created Form Auth username and passwords for them and they just have to remember both their Windows and web app credentials.

  44. Russ Painter says:

    Forms should be the default since it works everywhere.  I have used windows auth, but only as an add-on because even in that environment my users want to be able to connect remotely from anywhere.

  45. TJ says:

    We always try to use Windows authentication when possible, since our campus uses Active Directory for a lot of things anyway, makes it much easier for the users to remember their accounts and passwords.

  46. We sell LOB apps as our primary business. In my experience, We always start out with Forms authentication because a lot of our clients are small companies or small departments of larger companies. Occasionally, they will request that we authenticate against their active directory, but we still use forms authentication so that the client’s clients can still access the system as well, but internal staff don’t have to remember more than one set of credentials. This hybrid approach work very well for us until they request the inevitable hybrid SSO. We have tried various solutions, but they all seem sort of hack-and-slash. I wish there were better out-of-the-box solutions for this.

  47. Matt says:

    All of our applications use Forms Auth.

    I would imagine that if you’re writing an application for a corporation’s use, and you’re selling the app to run on their servers, Windows Auth may make more sense (single username system).

    However, if you’re writing apps that you will host yourself and that you sell/license use of the application to customers, then Form Auth is the way to go.

    My suggestion is to put a question in the ASP.NET Application Wizard for which way to go along with some of the options.

    …Matt

  48. Yanzheng Li says:

    Personally I prefer form auth. I think it’s more flexible in terms of development and extensibility. Windows auth also has a lot of advantages, as both of them have their respective pros and cons. I guess the choice of form/win auth would really depends on the context and the environment the application is utilized. Win auth is more suitable for intranet apps and form auth is probably more familiar and easy to develop for many people creating just ordinary web apps for the general public.

  49. Matt says:

    In addition, I think there needs to be a mechanism for showing a forms-auth-type username/password form but use Windows auth on the back-end.  This would prove useful for when people are accessing from outside the office.

  50. Jeff Becker says:

    I’d love to be able to do windows authentication but its just never been technically feasible.  Either we’re hosting our apps off-site, or the company has Active Directory so locked down we cant use it for authorization etc.  

  51. JohnGalt says:

    Since the overwhelming number of implimentations will be on publically facing web sites, Forms auth should always be the default and Windows Auth should be an optional setup.  Yes there may be more people using Windows Auth on a day to day basis to login, but not implimentations by a long stretch.

  52. Codeblaster says:

    As an ISV our products must allow both. Some companies that are AD based want to authenticate/authorized users based on their AD groups, some still want a separate auth system for our app. We still have a large part of customers that run our apps in workgroup environment and don’t want to rely on local users/groups.

  53. Deepak Bhatia says:

    I prefer Windows, not only easy to use and secure, but in case on onsite installation of software it does not require users to remember seprate credentials. Hower, for interner applications there is not option but to use Form authentication

  54. Jeroen-bart Engelen says:

    Forms auth.

    My office has a heterogenous environment and almost none of the Windows servers are connected to the same domain.

    That being said I would love to try some Windows auth. It all seems much easier then developing yet another username/password box or username/password field in the web service.

  55. Kashif says:

    WinAuth only for internal apps

    All external "web apps" FormsAuth

  56. Krunal says:

    We also use form auth in all of over web applications.

  57. Alex says:

    We are using Window auth. in our ERP application, Single sign on behaviour is great for user, no need to remember a bunch of passwords

  58. Ryan R. says:

    My preference is to use Windows Auth because of the reasons you mentioned.  It’s simpler.. no passwords to remember.

    But there are certain situations that require Forms Auth (like shared PCs).  For example, a project I’m currently working on needs to use Forms Auth because the users need to be able to login/logout of the application without having to logout of the PC.  This would be a huge hassle for them.

    As far as project templates, I think that these should support Forms Auth by default, just because I feel that it’s much more common, and more challenging (though not by much) to set up.

  59. Ben Hayat says:

    Let me ask you this Brad, if you were to build a SL app that some of the users are on Mac, how would you do it with Windows authentications?

    Thanks!

    ..Ben

  60. Peter Ritchie says:

    In any serious enterprise application that I’ve been involved with, it’s always gotten down to Windows (or AD) authentication.  The management of users and privileges is almost always the domain of someone other than the team developing the application and they don’t want to built and administrative front-end to manage users and privileges when AD/Windows already does it for you.

  61. Jerome Vernon says:

    Hi Brad,

    Why not both – using dual authentication via extending/implementing the MembershipProvider class. In most cases an extended user data table is needed for such thing as address and other application specific information. A network Guid Id column can be added to this table for the purpose of identifying, adding, removing (or disabling) network users in the forms authentication data store.

    In an IIS website, for anonymous access, active director is not available. To allow for public access and also provide automated identification for network users, two IIS websites can be created, both pointing to the same virtual path. One of the websites has the anonymous access checkbox checked, the other (for network users) does not. An application timer event can manage scanning the active directory and updating user data store (and user roles table) on a periodic basis.

    On session start, if System.Security.Principal.SecurityIdentifier UserSID = HttpContext.Current.Request.LogonUserIdentity.User; returns a valid SID then the extended user data table can be queried. If the user is not already authenticated via persistent cookie; automatic login could be triggered to occur via session state variable in a custom page base class.

    In any event, It’s my opinion that whatever authentication method or data store utilized; it should remain, and be enforced at the presentation layer being completely isolated from any application specific persistence mechanism (ie… MVC and entity frameworks).This general rule will help ensure compatibility across tiers and current/future applications.

  62. Raj Kaimal says:

    We have been using ASP.net since the beta days. Almost all our apps use forms auth. Not everyone has a windows domain account.

    All the applications go through a Single Sign On application (like your Geneva server).

    >Should we be wiring these up to support Forms Auth by default

    Absolutely. With support for federated login.

    Raj Kaimal

  63. Jon says:

    Windows auth is pretty much never used in our environment. I would like to see basic auth added to ASP.NET. It would come in handy for RIA apps IMHO. I had to create a custom HttpModule to do it and it was a lot more complicated that it should’ve been.

  64. Jon says:

    We have an LDAP directory that we use for most authentication. For web apps we use forms auth mostly, but, HTTP basic auth is needed for web services. That is why I would like to see a Basic auth authentication type added to ASP.NET. Microsoft has the tendency to assume that everyone uses all Microsoft and nothing else. Unfortunately to Microsoft’s dismay, that is not the real world.

  65. Muthu K says:

    Forms authentication is the convenient one.

  66. Jim says:

    Intranet and Extranet: always Windows authentication

    Internet only: Forms authentication

  67. Steve says:

    Forms Auth for a variety of reasons.

  68. Ricardo says:

    Definitely Forms Auth… IMHO, with Silverlight becoming a rich platform for business applications this approach will become even more common.

  69. Kevin Daly says:

    Windows Auth is the logical choice for an intranet application – people generally want to log on once to the network and leave it at that.

    However, it is often still desirable to use Sql Server  for roles rather than relying on Active Directory (which can be a rather blunt instrument for many purposes).

    So Windows Auth + SqlServerRoleProvider is an important but often overlooked combination.

  70. Ashic says:

    As I see it, Windows Auth works only in an all windows intranet. While many enterprise grade intranet apps are out there, it’s not really "web" and definitely not web 2.0+. Asp.net is one of the best tools for "websites" (or web apps – whatever). Most of the users of Asp.net are building websites, not all windows intranet apps. A lot of asp.net sites are hosted on shared hosting and a LOT of beginners don’t go all out for dedicated hosting. Having to go through a few complex (for the beginner) steps to enable authentication is definitely not good for someone starting out in Asp.net and touting it against php and other stuff. At the Asp.net forums, we see quite a few devs using their own very simple authentication schemes instead of using the membership API. We also see some more experienced posters support that cause "as a beginner, the membership API is very difficult to set up". They even custom code login / user creation controls instead of levereging the awesome system present in asp.net. Why do we see this? I’d go so far as to say that’s because asp.net defaults to windows authentication.

    Also, people building apps with windows auth (all windows intranet apps) are generally in an enterprise scenario. They’re not "beginners" who need hand holding. They’re accomplished devs in their own right (who’d hire a beginner to build an enterprise app?). They can easily revert to forms in a matter of a minute.

    Also, the windows authentication method gives users the convenience to log in to windows and be logged in to the intranet app. Believe it or not, I’ve had a few clients who don’t like this. They explicitly want to be able to log off and login using usernames and passwords. In a couple of apps I did with sensitive info, (both intranet on a windows only network) the client thought that being logged in automatically with windows could be a security concern. [Joe logs in, goes for coffee, Stan sits at the next desk and does stuff from Joes workstation seeing Joe forgot to log off / lock the pc.]

    So yeah, I definitely think defaulting to forms would help asp.net as a platform.

  71. obsid says:

    My personal belief is that it should be cardspace/Geneva Server first.  Idealy some way so that people can have "default" cards that they dont care who knows about.  So that you can "autologin" using your windows live ID automaticly to each website you go to (assuming you wanted to you would have to opt-in).  And then gracefully fall back to windows login if that is the only thing avalible, and then fall back to openID form login if nothing else works.  I dont think the tech is quite right yet, esp when it comes to cardspace to do this all correctly, but that would be the ideal.

  72. alvipeo says:

    For business apps I use Windows auth. But for more open web applications Forms auth is used.

  73. Ronald says:

    Whenever possible Windows authorization. In all other cases there should be some federated authorization like OpenID or the Geneva framework. I think Microsoft should make more effort to facilitate the developer for internet apps. For example more controls like an ‘OpenID selector’ or a cardspace control, which integrates easily with windows live and gmail, etc. Make it easy for us!!!

  74. David Jacobson says:

    There seem to be several realities.  One is that Windows authentication is very good technology for an application that will be deployed in a Windows environment.  A second is that Forms authentication is a very poor technology.  In many web environments, it may be the only viable choice.  But it should not be positioned as a quality technology.  For example, it seems to be relatively common for Microsoft sponsored web sites to have their own local registration and authentication instead of federating with Live ID.  Those cases are a disgrace to the compnay.

  75. As many have discussed, we use Windows Authentication for internal-only applications.  This provides the look and feel for ‘single sign-on’ for those who are logged into enterprise computers.

    For external applications (public/alternative authentication source), we use forms authentication or (now more commonly) OpenID.

    The biggest change we’re seeing lately is a migration away from Internet Explorer as our primary business apps are working less and less with IE and focusing on FireFox.  As more move away from IE, we will continue to reevaluate our authentication scheme and may be looking more at alternative single sign-on solutions.

  76. I have mostly used Windows Authentication, primarily because all of the application users are withing a corporate domain. Our entire company uses Windows clients and active directory, so no Forms authentication required.

    The question whether using one or the other authentication mechanism is directly tied to the deployment environment, domain infrastructure, intra vs. internet.

  77. Andrew N says:

    Working in a Hospital, we have a lot of Generic PC’s as clinicians switch PC’s all the time, so they do not log on using their AD credentials.

    So, the applications we build need to use forms authentication.  However, we implemented our own authentication provider which connects to AD to check the credentials.

    So we are using forms auth, but get the benefit of users only having to remeber one password.

  78. Brian says:

    Are you kidding?  I can’t believe you had to even ask.  Microsoft has been selling/positioning Silverlight is a WEB technology…to the point you’re comparing it to FLASH/FLEX.  YOU should always design for the WEB first … then intranet.  Forms authentication should be your highest priority!  PLEASE!

  79. Thomas says:

    At least three scenarios should be catered for:

    1. Forms Auth only

    2. Windows Auth only

    3. Windows Auth with ‘fall-back’ to Forms Auth

    regards

  80. Derek says:

    Forms Authentication, I’ve never even seen a chance to use Windows Authentication.

    Though I’ll be frank, I’m not very fond of the default membership system that was introduced in .NET 2.0. It’d be really nice to see it re-hashed as something much more slimline and versatile, instead of relying on clunky keys that we have to jump through hoops to work with.

  81. Pragnesh says:

    form Authentication.

    used Windows Auth in past.

    but most commonly form auth.

  82. ShadowChaser says:

    We use forms auth between our corporate network and the "hosting facilities".

    IT maintains a strict separation between the two – the live/production Windows domains have no trust relationships or intranet access to the internal LAN.

    All web authentication is done via forms.

  83. I’ve used Windows Auth exactly once in the past eleven years, and it was a dual windows/forms auth application. Everything I do, though, has at least some public-facing component and no one wants to create loads of AD logins for public users.

  84. Steve Wood says:

    Forms Auth for all the way.  Used Windows Auth years ago, in classic ASP intranet applications, but only Forms Auth in the past 9 years or so.

  85. Custom auth.  I’m tied down in more ways than I’m comfortable with already.  I hate to say it, but the less I rely on built-in schemes (that can and do change, sometimes even in a simple service pack), the better off we are.  As far as maintainability goes, anyway.  Oh, and consumer confidence.  =P

  86. Chuck says:

    I want to use both in the same application!

    We want our internal users to be able to just open the site without having to login. We authenticate them for various applications and roles using internal logic.

    But, I want the same sites to be available to certain external users as well, using a traditional login/password scenario.

  87. jakb says:

    Yep – Forms authentication works for me…

  88. Nima says:

    Forms Authentication for sure!!

    Windows authentication just isn’t worth the effort for anything other than a small Intranet app.

  89. Eugene says:

    I am going to go out on a limb and generalize here.  

    Large enterprises (that use windows pc’s) mostly use windows authentication.  Why – because the volume of help desk calls w/ multiple sign in’s goes up exponentially.  So its a cost / simplicity thing.  SSO.

    Smaller shops or anything externally facing would never use Windows Auth… So its either forms or custom.  

    As for what you should include in your templates.  Well – that seems like an easy question.  Who are you guys targeting?  Enterprises or web / smaller developers?

    Answer that and you have an answer to your question.  

    Then again, this may not be an easy question to answer at all.

    I think MS has gone back and forth.  For a while ASP.NET 2.0 was all about controls.  Controls like break crumb controls.  I have nothing against bread crumbs, but it seems like a waste of MS talent.  You were surely targeting public web developers.

    Now things have shifted more to the enterprise again, or at least have balanced out.  I like it.

    You can guess which side I come from.

  90. En says:

    Forms for outward (interet facing) apps.

    Windows for intranet / internal LOB apps.

    I like the forms authentication model, but hate the out of the box membership controls for anything other than small projects.

    So if using forms auth I always use the FormsAuthentication class directly and use a custom member store.

  91. メル友募集のあそび場「ラブフリー」はみんなの出逢いを応援する全国版の逆援助コミュニティーです!女の子と真剣にお付き合いしたい方も、複数の女性と戯れたい方も今すぐ無料登録からどうぞ

  92. 簡単にお小遣い稼ぎをしたい方必見、当サイト逆¥å€¶æ¥½éƒ¨ã§ã¯ç„¡æ–™ç™»éŒ²ã—て女性の性の欲求に応えるだけのアルバイトです。初心者でもすぐに高収入の逆¥äº¤éš›ã«èˆˆå‘³ã‚’もたれた方はTOPページまでどうぞ。

  93. プロフ作りました。興味ある方連絡まってま〜す。メアドを乗せておくので連絡ください。色んな人の色んな話聞きたい感じですのでヨロシクhappy-my-life-.-@docomo.ne.jp