HT/VT Web Site

Discussions around miscellaneous technologies and projects for the general membership.
User avatar
brado426
Member
Posts: 313
Joined: Sun Feb 11, 2007 9:50 pm
Location: Foothill Ranch, CA
Contact:

#11

Post by brado426 »

mkmurray wrote:I really like what brado426 has done so far, and I think it would be neat to have it fit right in with the look of other Church sites.

Thanks, mcmurray. The HT/VT Website is written in C# utilizing Microsoft ASP.NET 2.0. It also uses cascading style sheets for the look and feel. I have not asked about or looked into what the Church uses to style their websites, but I'm guessing they probably have a library of CSS styles somewhere. I haven't really bothered styling this HT/VT application yet because I figured the Church probably had a library of their own that would make the process a lot easier. I'm no artist... I can make a site functional, but I'm not so great at making it look pretty; So any shortcuts I can take to make my websites look half-way decent are welcomed. :)

It would be nice if such a stylesheet library was provided to the community.

Brad O.
User avatar
hpaulsen
Member
Posts: 112
Joined: Fri Mar 09, 2007 12:53 pm
Location: Barstow, CA
Contact:

#12

Post by hpaulsen »

tomw wrote:
  1. How do we securely integrate this into internal systems here at the Church that are currently under development without exposing sensitive and critical data to the community. If we provide API's or other Web services to integrate into these systems, do we expose the Church and the privacy of the data to people wanting to use those API's for non-approved purposes?


The API's/web services would not have to have direct access to sensitive data if they only work server-side (e.g. php). Developers could work with a local mySQL/php mockup of the website with a test API designed for that, then upload their changes to the code repository for approval. Only approved changes would be added to the site and have access to the 'real' API and data.

One side effect of this, which has both positive and negative aspects, is that people would not be able to create their own live programs for using the API (e.g. create a website on their own site that ties in to LUWS that farms for emails/phone #s to advertise some lds-oriented product/service - I can definitely see this happening semi-innocently). The only projects with access to live info would be those approved by the development team.
User avatar
bhofmann
Member
Posts: 272
Joined: Tue Feb 06, 2007 9:47 am
Location: Tulsa, OK
Contact:

#13

Post by bhofmann »

haledn wrote:As far as verifying the quality of the code and ensuring that no security holes are introduced... I think that we can follow the model that many other open source applications have utilized. As long as enough people are actively working on the project, you will be able to quickly identify bugs and keep the quality up.
I agree with haledn. We should be successful following the project model for successful open source projects. They've proven to be high quality, efficient, and secure.
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

#14

Post by WelchTC »

RussellHltn wrote:As for testing - expanding on my idea of the test ward/stake, how about test membership record numbers and test logins to LUWS? The logins can be shared among testers allowing multiple people to test the different roles. Done right I think we can run the test on a live system without messing up the real data. We just have to be careful about move-in and move-outs that they don't go to real units.

Then again, how does the church test their back-ends? Do they have a membership system testbed?

Oh, and those test units: Ward Unit #108, Stake Unit #2224445.
We do have test data and I would suppose that we would setup a test data environment.

Tom
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

#15

Post by WelchTC »

mkmurray wrote:By the way, Tom, this is really exciting news!
I understand what you're asking, but yet I don't think I am grasping all of the concerns...Are you speaking about security vunerabilities of the data itself, exposure of internal Church systems, or maybe both? If it's the data, what type of data might be passing through the app of a secure nature? If Church systems, are we talking solely about databases, or does it go further than that? If I can get a better idea of the concerns here, I might have some decent comments to contribute...Thanks.
I'm not sure if I have any concrete examples or explainations. I'm curious as to what the community feels are our security concerns. From the Church's position, there is a lot of very sensitive data that we need to all access to only those who should have it. Obvioiusly we can create a test database of data that developers can hit but once a developer knows how things work, are we exposed to developer hacks to get around security?

Tom[/align]
User avatar
thedqs
Community Moderators
Posts: 1042
Joined: Wed Jan 24, 2007 8:53 am
Location: Redmond, WA
Contact:

#16

Post by thedqs »

HPaulsen wrote:[/align]The API's/web services would not have to have direct access to sensitive data if they only work server-side (e.g. php). Developers could work with a local mySQL/php mockup of the website with a test API designed for that, then upload their changes to the code repository for approval. Only approved changes would be added to the site and have access to the 'real' API and data.

One side effect of this, which has both positive and negative aspects, is that people would not be able to create their own live programs for using the API (e.g. create a website on their own site that ties in to LUWS that farms for emails/phone #s to advertise some lds-oriented product/service - I can definitely see this happening semi-innocently). The only projects with access to live info would be those approved by the development team.

Though since they would have to use their own username and password they would be limited to the data they have access to and so they could only use it as they can now. If someone really wanted to harvest the data just download the vCard of the stake directory and parse it. Not much harder then using the API. Now if you are taking about global information on the church that I believe is a NO NO for anyone. And of course you could only change your personal information. So I think the API should be able to read what your username has access to and change what your username can normally change.
- David
User avatar
thedqs
Community Moderators
Posts: 1042
Joined: Wed Jan 24, 2007 8:53 am
Location: Redmond, WA
Contact:

#17

Post by thedqs »

tomw wrote:
I'm not sure if I have any concrete examples or explainations. I'm curious as to what the community feels are our security concerns. From the Church's position, there is a lot of very sensitive data that we need to all access to only those who should have it. Obvioiusly we can create a test database of data that developers can hit but once a developer knows how things work, are we exposed to developer hacks to get around security?

Tom

As I see it if the API requires you to securely initiate a session with the server using your username and password then you'd be limited to what your username can do on the site anyway. I just see the API as a way to interface with LUWS or any LDS service with slim data that can be used quickly in the program.

As it is right now you have to parse the webpages to get access to the data and that can be annoying since we all know that HTML is not very strict and isn't a good method for transmitting data (thus XML was created).
- David
User avatar
thedqs
Community Moderators
Posts: 1042
Joined: Wed Jan 24, 2007 8:53 am
Location: Redmond, WA
Contact:

#18

Post by thedqs »

bhofmann wrote:I agree with haledn. We should be successful following the project model for successful open source projects. They've proven to be high quality, efficient, and secure.

Also open-source with enough developers means that projects won't stagnate.
- David
russellhltn
Community Administrator
Posts: 34421
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

#19

Post by russellhltn »

tomw wrote:Obvioiusly we can create a test database of data that developers can hit but once a developer knows how things work, are we exposed to developer hacks to get around security?
I think there is some small exposure. But then I think you are more likely to have someone point out the flaw.

Which is more secure - security though obscurity, or security though a bunch of computer geeks looking over the shoulder - all with a vested interest in keeping things secure? I will admit the first case is more smooth and peaceful. :D
User avatar
bhofmann
Member
Posts: 272
Joined: Tue Feb 06, 2007 9:47 am
Location: Tulsa, OK
Contact:

#20

Post by bhofmann »

RussellHltn wrote:I think there is some small exposure. But then I think you are more likely to have someone point out the flaw.

Which is more secure - security though obscurity, or security though a bunch of computer geeks looking over the shoulder - all with a vested interest in keeping things secure? I will admit the first case is more smooth and peaceful. :D
I agree and we've seen this on this forum. When ever there is an infraction it is the general forum members that find and report more often than the moderators. I think it would be pretty difficult to slip something in with everyone collaborating on the project.
Post Reply

Return to “Other Member Technologies”